[Gdal-dev] GNUmakefile cleanups (libtool related)

[Simon Perkins]

On Thu, 2003-07-10 at 13:52, Alessandro Amici wrote:
> i investigated a bit more the possibility of using libtool in the gdal build 
> and i think i can counter most of the comments you raised in your last email 
> on the subject. in the meantime, i managed to actually build (a seemingly 
> correct) libgdal.so with libtool. unfortunately the current incarnation of 
> the patch is ugly enough to be embarrassing ;).

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

I've used libtool, automake and autoconf for a few projects, but my
personal feeling is that, while autoconf is usually a good thing, and
automake is often a good thing, libtool is usually a pain in the butt,
for the following reasons:

- Obscuration of the build process: although libtool is nominally only
involved with making shared libraries, it's approach is to completely
take over the entire build process and do all kinds of stuff that is
strange and mysterious. For instance, you will discover that the
executables you build are now just scripts which do a bunch of stuff and
then call the real executable which is actually living in some hidden
sub-directory of the build directory. If you do everything within
libtool then things probably work OK, but anytime you try to customize
the build process at all, you run into this obstacle of trying to work
out what the hell libtool has done with all your object files and so on.

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

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

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

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



In my own code, I stopped using libtool a year or so ago (where I had
that option). I still use autconf and automake which are generally
great, but I write my own rules for generating shared libraries. Yes, I
have to do something new for every new platform (admittedly that's not
really a big issue for the packages I work on, and I've only ever
bothered supporting linux and solaris), but I feel that I have a much
greater level of control over and understanding of the build process.


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


Rant off,

Sy