[GRASS5] Re: GRASS 5.1 build system

[Glynn Clements]

Radim Blazek wrote:

> > 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 3 is "the right thing", but it's also the most work.
> 
> Considering also your explanation in another mail, I think that it
> is "the right time" to do that now.
> 
> > 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).
> 
> So we can do the same.
> 
> How to proceed now? If others agree with 3., we need somebody who can write 
> new build system, example Makefile.in files and some instructions how to write
> Makefile.in rules. I would welcome examples especially for:
> lib/db/sqlp/
> lib/vector/diglib/
> display/d.m/
> visualization/nviz/*
> /vector/v.ascii/
> + common directory, library and module

Actually, I've just realised that we shouldn't actually need to
process the individual Makefiles at all; they can include the
generated .mk files using a relative path, e.g.

	CURDIR=lib/vector/diglib
	TOPDIR=../../..
	include $(TOPDIR)/mk/head.mk

	...

	include $(TOPDIR)/mk/tail.mk

Then, only the global .mk files need to be processed; the Makefiles
can be copied verbatim. Any build-specific information can be obtained
from the included .mk files.

As a general rule, the individual Makefiles should only contain
information which is specific to that particular directory. Mostly,
this boils down to the dependencies, plus any directory-specific or
target-specific switches. As much information as possible should go
into the global .mk files (e.g. pattern rules).

The main complications are:

1. You can't easily provide a pattern rule for linking executables[1]. 
There are a number of common approaches to this issue; however, many
of them impose a limitation of one executable per directory, and the
ones which don't tend to be ugly.

[1] Except for the special case where an executable "foo" is made from
a single object file called "foo.o", which doesn't really help us.

2. You can't assume that there will only be one executable per
directory (e.g. i.fft/i.ifft, r.in.tiff/r.out.tiff etc); otherwise you
could just define OBJS and let the .mk files handle the rest.

Basically, the goal is to ensure that, to the greatest extent
possible, any changes to the build system only involve changing the
global .mk files and not all of the individual Makefiles. I don't mind
re-writing the core build system ad infinitum until it handles every
imaginable scenario perfectly, so long as I don't have to re-write
~1000 Makefiles every time.

I'll look into this over the next few days and get back to you. Also,
I'll replace the existing configure.in with one which is based upon
the one from 5.0.

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