[GRASS5] Re: OGR-enabled GDAL

[Glynn Clements]

Paul Kelly wrote:

> > > I see. This is the general problem that there is no mechanism in the 5.1
> > > build system for optionally compiling programs, like LOC_OPTIONAL in 5.0.
> > > I think it should be a more general solution as there are lots of modules,
> > > like this, e.g. that depend on libtiff, libpng, OpenGL etc. and they
> > > should all be compiled optionally depending on what the configure script
> > > finds.
> >
> > Why variables from Platform.make cannot be used as conditions in Makefiles
> > (like in vector/Makefile and db/drivers/Makefile)?
> 
> Maybe---I don't know what is best but it just seems a more elegant
> solution to me to do it all within the configure script. I don't
> understand it well enough to explain; I just have a feeling about what is
> the best way to do it :)

There are advantages for both approaches.

One advantage of the src/CMD/lists approach is that it's easier to
implement error recovery; failure to build an individual entry in the
list doesn't terminate the rule.

To do this with a conventional "recursive make", each "directory"
Makefile would have to explicitly build its subdirectories in such a
way that failures don't propagate; e.g. by using a loop, so that the
entire process is a single command from make's perspective, or by
forcing a successful exit status from each command ("... ; true").

Similarly, there are advantages to having the test for whether to
build a particular module localised to that module's Makefile. OTOH,
the test would have to be repeated for each rule (program, docs,
install, etc), whereas modifying a global modules list would affect
all rules.

> > > It looks like the alternative build system (grass/mk) in GRASS 5.0 gives
> > > some ideas of how this could be done. It comes down to maintaining the
> > > old-style module lists  (src/CMD/lists/GRASS and src/CMD/lists/optional)
> > > in 5.1 and the top-level makefile compiling all the modules contained in
> > > those lists. Instead of the sub-directory Makefiles containing a list of
> > > all the modules like they do now (why was it changed like this when 5.1
> > > CVS was set up?).
> >
> > As I wrote already many times, 51 cvs was created to enable to work together
> > on new vectors (when David was here). I did the best I was able to do,
> > I used another 'alternative build system' which was available that time.
> > I thought that some expert can improve/replace it later, unfortunately nobody
> > did anything better.
> > So again, I don't insist that current make system should be kept for future.
> > Don't hesitate to remove it and do something better!
> 
> I always thought it was quite good. I just don't understand it well enough
> to know if there was no optional building on purpose. But thinking about
> it now I suppose the optional build system was only added to 5.0
> when the 5.1 build system was already in operation (this answers the
> question).

That's correct. I did quite a lot of work on the 5.0 build system
after the 5.1 system had been derived from it.

> So there would be no harm then in adding the optional build system
> to 5.1 as well maybe.

However, note that a number of decisions regarding the 5.0 build
system were constrained by compatibility issues. The alternate build
system was constrained by the need to avoid interfering with the
gmake5 mechanism, and other aspects were then constrained by the
desire to maintain compatibility with both build mechanisms
(personally, I only use the original gmake5 mechanism to test that it
still works).

I would like to revisit the build system issue at some point. Key
issues for me are:

1. Out-of-place builds (i.e. not modifying the source tree).

2. Building from a read-only source tree (closely related to point 1).

3. Correct handling of dependencies.

4. Supporting shared libraries, without using libtool (related to
point 3).

5. Tying building of documentation to building the corresponding
module (i.e. no installing manpages for non-existent modules).

Point 1 is already dealt with by the alternate build mechanism. The
main issue with point 2 is the use of "cp" instead of "install" (if
you use "cp" on a read-only file, the copy is also read-only).

Point 3 has been significantly improved in the 5.0.x tree, primarily
through having separate FOOLIB and DEPFOOLIB variables. This also
deals with the main issue for shared libraries (you can't just use the
library's pathname as a linker argument).

Point 5 involves moving the documentation into the module directories,
so it's rather more involved than the others.

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