[GRASS5] Re: OGR-enabled GDAL

[Paul Kelly]

On Wed, 27 Aug 2003, Glynn Clements wrote:

>
> 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.

I have come round to the idea of using the Makefile variables included
from Platform.make in all the Makefiles. This involves not too many
changes, which is always best as it is less likely to break other things.
So for each enabled functionality, there already is a variable within the
configure script set to 1, e.g. USE_OGR=1 or USE_GD=1. So we just need to
add AC_SUBST(USE_OGR) to the configure script and USE_OGR=@USE_OGR@ in
Platform.make.in and the the value of USE_.. will be substituted into
Platform.make. And in the Makefile where the modules are listed, just test
for this variable not being empty and if so add the dependent module's
directory to the SUBDIRS line in the Makefile.

I did it for OGR (v.in.ogr/v.out.ogr) and GD (PNGdriver) in GRASS5.1 and
seems to work fine.

>
> 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.

The way I did it (that Markus had already started) is in the top-level
directory for each class of modules, i.e. vector/Makefile for all the
vector modules, and involves just compiling or not compiling the whole
directory so I think that works around that potential problem.

But the above change so one module failing doesn't stop the whole build
process and failed modules can be written to an error.log file, still
needs to be done some time.

Paul