[Gdal-dev] GNUmakefile cleanups (libtool related)
alexamici at tiscali.it
Thu Jul 10 17:21:10 EDT 2003
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
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
> - 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.:
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
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!
More information about the Gdal-dev