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

[Frank Warmerdam]

Sy,

Thats good information.  I assume you have been pleased with it so far in
actual use?

While I am in no big rush to rework the GDAL build architecture again just
now, I am wondering if OpenEV might not benefit from this.  Currently OpenEV's
build structure is pretty half-assed, and OpenEV builds are currently pretty
complicated.  Also, OpenEV requires Python, so we wouldn't have to worry about
gripes from the folks who don't want to have to install Python.

I will try to look at this at some point for OpenEV.

Simon Perkins wrote:
> 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

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent