one build tree

[Gavin Koch <gavin cygnus com>]

Tom Tromey writes:
 > Russ> It seems that some of the packages need to be compiled and
 > Russ> installed before other packages can be compiled.  Isn't that a
 > Russ> job for a Makefile?
 > 
 > Yeah.  Here at Cygnus we have all our source in a single tree.  You
 > can either check out parts of the tree (e.g., gdb and the stuff it
 > needs), or check out everything.
 > 
 > There is a top-level configure script (hand-written; it predates
 > autoconf) and Makefile which can be used to configure and build
 > everything.
 > 
 > If you look at a net release of gdb or binutils you can see this in
 > action.  These are just snapshots of different subsets of our tree --
 > locally I could check out gdb+binutils+gcc+whatever else and build it
 > all with two commands ("configure; make").

One tree to rule them all,
One tree to find them,
One tree to bring them all,
and to itself bind them.

        (Apologies to Tolken)


I would like to encorage the Gnome project not to go
the "one build tree" route.  The goal of this kind of
system is to simplify things for the end user, and it
does to that, but the cost in terms of extra work for
package developers is not worth the small gain in
simplicty.  (This is, of course, just my opinion.)
There are other ways to simplify things for the end
user.

What makes this "one build tree" system harder for developers
is that it complicates makefiles (and related configury stuff).
Makefiles under this system are forced to deal with the
case that libraries, header files, executables, etc. of 
other packages that they depend upon can be in more than
one place: either the normal installed location, or in the
build tree of the dependee package, or the source tree 
of the dependee package.  This increases the amount of
work needed to build a correct makefile, and creates new
dependancies on how the dependee's source is organized,
and built.  (Sorry about the word "dependee";  I'm not
sure what the complement of "dependant" is.)

To be fair/accurate, the "one build tree" system does *not*
make it *lots* harder to create correct makefiles, but it does
make it harder.  Any why make things harder if you don't
have to.

I don't think it is too much to ask of end users to build 
and install separate packages in a particular order.

   cd <package-one>
   ./configure
   make all install
   cd <package-two>
   ./configure
   make all install
   cd <etc>
   ...
   ...

is just *not* that much more complicated than

   cd <all-packages-combined>
   ./configure
   make all install

particularly if each package is clear about what other
packages need to be installed before they can be built.

Most of you will notice that it would be possible to
create an overall makefile that does something like 
sequence one above, and, by its nature, presents
sequence two to the user.  I agree, and don't object
in general to such a makefile.  The critical piece,
from my perspective, is that each package is installed
before moving on to the next, and each package finds it's 
dependancies in the installed locations.

In some cases, the dependancies between two (or more)
packages are such that it is just not possible to 
simply make and install one package before going on
to the next.  Such is the case with gcc, binutils,
and related language libraries.  Particularly for
cross-compilers, and particularly so back when 
Cygnus started the one build tree for these packages.
Things have gotten better between these packages, but
still not as simple as build-install one; build-install
two.  It may be the case that there are sets of packages
within gnome that have complicated interdependancies
that justify a single build tree for those packages,
but that should be the exception rather than the
rule.

Downloading a single tarfile (or cvs tree), and doing
a single build-install *is* easier than downloading 
and building, and installing multiple packages.  One
touch building of the Gnome system would be a *good*
thing, but I would encorage you not to break the 
simplicity of the existing package interfaces to get
this feature.

                                  -gavin...