[GRASS5] Re: GRASS 5.1 build system

[Glynn Clements]

Radim Blazek wrote:

> > 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).
> 
> But compile more platforms in the same source tree at the same time
> each in its $(ARCH) dirs should be possible?
> 
> Do you mean multiple systems with identical $(ARCH) but other differences
> like versions of libraries?

There are three distinct issues which the existing (gmake5) mechanism
doesn't solve:

1. Multiple builds for the same value of $(ARCH). Either multiple
builds for the same target but with different options, or builds for
multiple targets which happen to have the same value of $(ARCH).

2. Building from a read-only source tree, e.g. a read-only NFS export
(or a writeable NFS export, but one where you don't want to have to
give write permission to everyone who might wish to build GRASS;
compiling the code and modifying the code are very distinct
operations, so the permissions should be orthogonal).

3. The fact that the existing mechanism doesn't quite work; while
object files are kept separate for different $(ARCH) settings, there
are still conflicts for Makefile, config.h, and all occurrences of
lex.yy.c, y.tab.[ch] etc.

Issue 1 could be solved by simply allowing the user to choose the
suffix. Solving issue 3 would create similar problems to those which
already apply to the "mk" mechanism.

In any case, the existing mechanism already has many of the same
problems as the "mk" mechanism; it just hides them within the gmake5
and GISGEN.sh scripts.

Both mechanisms operate with the source directory as the current
directory, and explicitly place generated files in a separate
directory.

However, the "mk" mechanism is more thorough (it handles all generated
files, not just object files), it solves issue 2 above, and the
overall mechanism is a lot simpler than gmake5 + GISGEN.sh + src/CMD/*.

The main advantages of option 3 (a conventional out-of-place build
mechanism) are that:

a) the build tree contains a complete set of specialised Makefiles, so
you can use "make -C <any directory> ..." without having to provide
any "-I" flags, and

b) GNU make has some built-in support for working this way (e.g. 
vpath), so the Makefiles are cleaner (e.g. no need to explicitly use
$(OBJDIR) everywhere).

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