[GRASS5] GRASS 5.1 build system [Was: Re: GRASS 5.1 with shared libs problems]

[Glynn Clements]

Radim Blazek wrote:

> > AFAICT, Radim developed the 5.1 build system, so it might be better to
> > ask him. It isn't that I'm unwilling to do anything in this area, just
> > that anything which is done needs to be coordinated between the
> > relevant parties.
> 
> I would not say that I have developed 5.1 build system, I just wanted
> to work on grass 51, so I wrote something which enables that. I expected
> that somebody who knows more about that, could improve/rewrite it, see:
> http://grass.itc.it/pipermail/grass5/2002-January/001533.html

OK. For future development, there are three main options:

1. Work with the Makefiles which are already there.
2. Port the alternate build mechanism (the one in "mk") from 5.0.
3. Write a conventional build mechanism which supports out-of-place builds.

Option 1 has the disadvantage of not supporting out-of-place builds. 

If you just want to compile and install GRASS, this isn't a problem. 
However, it is useful for development (e.g. allowing you to keep
multiple build trees around), or for large sites (where you may wish
to build GRASS on multiple systems from a single shared source tree).

Option 2 is a bit of a hack, as the system was constrained by the need
to cooperate with the existing gmake5 mechanism. Its main problems
are:

a) the need to pass the paths to the source and build "mk" directories
to "make" when building individual subdirectories, and

b) uncertainty as to whether the [ab]use of yacc's "-b" switch (to put
the output file in another directory) is portable.

Option 3 is "the right thing", but it's also the most work.

With a conventional out-of-place build mechanism, "make" operates with
the current directory set to the build directory. Source files are
located according to make's VPATH setting, while output files are
placed in the current directory. The Makefiles live in the build
directory; these are generated from the corresponding Makefile.in
files by the configure script.

[Note: autoconf supports some of this automatically; e.g. 
AC_OUTPUT(foo/bar) reads $srcdir/foo/bar.in ($srcdir is determined
from the pathname of the configure script or the --srcdir option) and
writes foo/bar relative to the current directory.]

The main complications with this are:

1. The configure script needs to obtain the list of Makefiles to be
generated (although this can be automated; you can use shell variables
in the argument to AC_OUTPUT).

2. Having configure generate lots of Makefiles via AC_OUTPUT is
potentially slow. As the actual Makefiles only need two specific
substitutions (to insert the source and build directories), it may be
better to perform this part with a dedicated script similar to the
existing mk/mkmakefiles. OTOH, Mozilla doesn't feel the need to do
this (it just passes ~1000 filenames to AC_OUTPUT).

3. Local header files won't be in the current directory, so you have
to add an explicit "-I$(SRCDIR)/$(CURDIR)" to the preprocessor flags
(and each Makefile must define CURDIR to be the relative path to the
directory from the top of the source tree).

-- 
Glynn Clements <glynn.clements at virgin.net>