[Gdal-dev] GNUmakefile cleanups (libtool related)

[Alessandro Amici]

Simon,

thanks for joining the discussion :) 

> I don't think I saw Frank's earlier e-mail, unless you're talking about
> a very old one, but I have a few comments...

yes it is an old one, where he had concerns similar to yours. i had holidays 
and a lot of work since then!

this is not meant to be an exaustive answer to all the point you raise, but 
just an ACK: i'll try to keep in mind all the things you all come up with and 
this will help me and Frank making the right chioces (i'm no libtool fanatic 
after all).

as i said, i plan to add a configure libtool option at first (it's quite easy) 
so people may test it on all the platforms and find weaknesses without being 
completely screwed.

[snip]

> - Doesn't work all that well with C++: The autotools suite has a
> definite C bias. A year or so ago, I found that libtool was unable to
> build a C++ library on solaris without platform specific hacking, which
> of course is exactly what libtool is supposed to save you from! GDAL is
> a C++ library at heart.

this is probably the major point i overlooked up to now (but it works for me).

> - Compatibility issues: the three components of autotools are not always
> updated in sync. We have run into problems where we upgrade, say,
> automake to get better java support, and then find that the latest
> version of libtool won't speak to it anymore. In addition, backwards
> compatibility doesn't seem to be a huge priority on the autotools
> developers' minds. Although my main gripe here is with autoconf, which
> seems to redefine major macros on almost every release.

as far as i am concerned gdal will still use its current GNUmakefile build 
structure (that is: no out-of-sync automake).

> - Efficiency: libtool pretty much insists on building every object
> twice. Once for the shared library and once of the static library. Or is
> there a way to stop it doing this?

there are several standard work-arounds, i.e.:
./configure --with-pic
builds the static lib with pic code as well.

> - The Need: For me the big question is: what does libtool give us that
> we don't have already? Sure there are a couple of things that could do
> with tidying up in the current process, but I can guarantee that libtool
> will require at least as much effort to get going. Particularly if the
> use of C++ means that you have to write special rules for each platform
> anyway.

did you realize how much of the build system is dedicated to the shared-static 
problem? a whole lot!
and how fragile it is? i already hit a couple of really non-trivial behaviors 
of the current build system while building the debian package.

> For my next project though, I'm seriously considering the use of an free
> software autotools replacement called SCONS. This seems to be a single
> tool that has all the major functionality of autoconf, automake and
> libtool (and more), but in addition has a much nicer syntax since it
> uses python as its implementation layer rather than the horrible mixture
> of shellscript and m4 that autotools uses. It also apparently works
> nicely on windows. Anyone out there used it? (http://www.scons.org/).

will look into it :)

> Rant off,

no problem! keep an eye on what i do and shout when i screw up!

cheers,
alessandro