[GRASS5] Re: OGR-enabled GDAL

[Glynn Clements]

Radim Blazek wrote:

> > 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).
> 
> OK, so I think that because of 1. and 2. the build system must be 
> completely rewritten.

When I did it for the 5.0 alternate build mechanism, most of the
changes boiled down to:

a) the configure script, and

b) bits in individual Gmakefiles which relied upon creating files in
the current directory.

The build system itself only required minor changes. Actually, b) was
only necessary because the generated Makefiles reside in the source
tree, which meant that the current directory was the source directory. 

A conventional out-of-place build system creates Makefiles in the
build tree, has the build directory as the current directory and uses
VPATH to locate source files. OTOH, most packages don't have as many
directories as GRASS.

I don't think that the usual approach of having configure generate a
bunch of "Makefile"s from a list of "Makefile.in"s using AC_OUTPUT()
is going to be feasible, as generating each file involves using a
massive "sed" command to substitute the entire autoconf environment. 
Assuming that we stick to GNU make (or, at least, makes which have an
"include" directive), the Makefiles can be copied verbatim; they just
need to be copied from the source tree to the build tree.

> > 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).
> 
> We have now separate *LIB and *DEP for all libraries.

OK; that's the main "enabling" requirement. Once that is the case, a
libraries dependencies should be made part of the *LIB variable, e.g.

	GISLIB      = -lgis $(DATETIMELIB) $(XDRLIB)

I can see that this is already done to an extent in grass51; it just
remains to do it systematically. In general, if a library requires a
certain depedency, that should be part of a the *LIB variable. The
Makefile for an individual module should only refer to those libraries
which the module uses directly (e.g. most modules shouldn't refer to
$(DATETIMELIB) explicitly).

In order to avoid gratuitous dependencies, certain peripheral
functions probably ought to be removed from the core libraries. E.g. 
unix_socks.c probably shouldn't be in libgis, as this results in the
libgis having a dependency upon the socket libraries (on platforms
where socket() etc aren't in libc itself).

> > Point 5 involves moving the documentation into the module directories,
> > so it's rather more involved than the others.
> 
> Documentation (at least manual pages) _is_ moved already to module directories,
> thanks to Markus, who has created the system generating man pages from
> options' description in the module + additional description.
> (Potential problem is cross compilation as you mentioned in other mail.)
> It works well. Regularly, Markus also tries to force me to write
> 'additional description' for new modules, but that does not work
> so well :)

OK; I should point out that my comments were directed at both 5.0 and
grass51. For 5.3 (or whatever the "intermediate" branch is called) we
need to decide whether to use the 5.0 gmake5 mechanism, the 5.0
alternate mechanism, the grass51 mechanism, or something else.

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