[Gdal-dev] porting of gdal to (optional) libtool build finally completed

[Simon Perkins]

On Thu, 2003-09-25 at 13:27, Alessandro Amici wrote:
> it has taken a good two months, but i'm finally ready to announce that the 
> optional libtool build is now ready for prime time :).

As one of those libtool non-fans you mentioned, I can at least
appreciate the effort required in getting libtool to work! :)


The following is a little tangential so feel free to ignore...

Don't know if I've mentioned this before, and if I haven't, this is
probably a tactless time to do so... but we've recently started using an
exciting new build tool called "scons" for our projects. The home page
for this project is at:

http://www.scons.org


Scons is billed as a "make replacement" but it is actually much closer
to autotools in scope. It works well on both windows and unix, does
almost all of the configuration and building stuff that autotools can do
(and is being steadily expanded), builds shared libraries, ditches make,
has an active user and developer community and is written in python so
it's very easy to extend. It has many nice featrues like direct support
for parallel compliation on multi-headed machines and it uses MD4
checksums rather than timestamps to do dependency checking.

Scons takes a slightly different (and in my opinion more modern)
approach to source builds than autotools. Autotools assumes that the
normal mode of distribution of a package is a source code tarball and
that a user must be able to configure and compile a tarball with a
fairly minimal (UNIX-like) system. Scons recognizes that these days (a)
most end users get their packages as binaries, and (b) developers
working with source code can be expected to have some more powerful
tools on their systems, such as python. The benefit of this assumption
is a very clean approach to builds that doesn't use make. The build
scripts that you write in scons are actually compact python scripts that
are directly executed when you ask scons to build your package.
Customizing your build is as simple as adding python code into the build
script. Customizing an autotools build is typically much more cryptic
since you are dealing with layers of different primitive languages such
as m4, shell script, automake and the make syntax itself, and you are
often writing code that has to write other code. Yuk!

The main drawbacks with scons are: (a) it's not as standard as
autotools, and (b) the documentation is currently not all that great,
although the developers are working on it apparently!

Anyway, just noting that there are alternatives to autotools. I'm not
volunteering to re-engineer the GDAL build process using scons right
now... :)

Cheers,

Sy