[wplug] Software builds.

[Bill Moran]

kabel <lists at voidship.net> wrote:
>
> A professor of mine recently got on my case as to how I build software.. he 
> advocates two directories, one for source, one for builds.  Packages get 
> their own subdirectory in each, with source going in the appropriate subdir. 
> and builds done in the other.  
> 
> I've never heard of doing it this way, and he may well have been referring to 
> a specific case, but does anyone else do this?  
> 
> What other good practices have I missed out on along these lines?

There are a few good reasons to at least make sure your build framework
is _capable_ of this:
*) It allows "make clean"ish operations to be safe and simple
*) It allows manual "make clean"ish operations to be safe.
*) If you have a big project, you can split source and obj on different
   disks and usually get a performance gain on build.
*) It allows you to make the source tree read-only.  This makes it safer
   to allow others to build your software, and even makes running
   automated builds less problematic.
*) It keeps obj files out of the directories where you're trying to work.

The best example of this I know is FreeBSD.  If you download the source
code to FreeBSD, it's designed to go in /usr/src, but it builds all its
obj files in /usr/obj.  The FreeBSD ports systems is capable of this as
well, but doesn't do it by default.

We find it damn useful because we mount /usr/src and /usr/ports read-only
via NFS on all our servers to save disk space, and give us a single tree
to keep up to date.

-Bill