[Mono-devel-list] momo on suse 9.3

[Massimiliano Mantione]

On Sat, 2005-07-23 at 00:23 -0700, Dennis Hayes wrote:
> do I install the Mono that comes with Suse, or from SVN, or install
> the Suse version, then up grade to the SVN version?

Ways of working are personal things (just like text editors), so...
use these advices at your own risk ;-)
Anyway, this is what I do:

- I use the packages available for my distribution as a sort of
  "stable reference", and keep them reasonably upgraded.
  I never mess with them because I use them to run the mono
  applications I really use (so I don't want them to break).
  Also, those packages install in the default places (/usr...), so
  I should be root to mess with them, which is something I don't
  like while hacking.

- I have one source tree I keep in sync with the svn repository.
  I work there, so it can (and does) break often.
  When I run configure, I specify a prefix that is local to my home
  directory, so that I never need to be root to build *and* install
  my "breakable" tree (all the mess is confined in my home).
  When I do a full rebuild, I typically do it cleanly in this way:
  make maintainer-clean && ./autogen.sh --prefix=/home/massi/mono && \
  make get-monolite-latest && make EXTERNAL_MCS=false
  I also have a shell function that puts the relevant directories
  first in the PATH, LD_LIBRARY_PATH and PKG_CONFIG_PATH variables,
  something like this:
  activate_local_mono () {
  pathmunge /home/massi/mono/bin
  	ldpathmunge /home/massi/mono/lib
  	ldpathmunge /usr/lib/mozilla
  	export PKG_CONFIG_PATH=/home/massi/mono/lib/pkgconfig/
  }
  (where pathmunge and ldpathmunge are other simple functions).
  So, if I want to work with the mono installed from my tree (which
  could be broken, but this is the reason why I use it!), I just have
  to execute "activate_local_mono", and I know that from there on in
  that shell (and *only* that shell) I will use my unstable code.
  That way can test/debug my system installed from the svn tree.
  
- If I need to work on more than one "patch" at a time, I save the
  state of my tree ("svn diff"), reset the tree to a known state,
  and work on the the "secondary" patch.
  When I'm done with it, I re-reset the tree, and re-apply the saved
  patch to get back my original "long term" working tree.
  The "hint" here is that "svn diff" captures exactly your work, so
  it is useful to backup it and restore it later.
  Just remember to do any relevant "svn add", or the diff will miss
  your new files...

Hope this helps... and if not, never mind :-)

Ciao,
  Massi