Torsten Sadowski <moehl at akaflieg.extern.tu-berlin.de> wrote:
> After all your work, would you say GNU autotools are worth the effort? I
> have had many cases where they fail and where I think a handmade makefile
> with some (documented) lines for local configuration would be better.
> 

Good question.  Forgive me if I beat Goran to the punch.

The really nice part of the autotools is the tests, i.e. autoconf
proper.  It would be nice to reuse those as much as possible.  I doubt
we can beat autoconf in this area by writing our own tests.

For the rest, I agree with your overall approach.  I'd just suggest that
the settings file *optionally* gets populated by autoconf, while still
being settable by hand.  (This latter is something that heavily
autotoolized programs frequently do not allow!)

The one other piece of autotools that seems promissing is libtool.  I
have had great pain with libtool, but what alternative do we have if we
want to compile shared libraries on lots of different Unices?  Insist on
gcc?  I guess we could do that....


Given the above premises, what I do when I put together build scripts in
other software is to use a combination of jam plus autoconf.  autoconf
is used to populate *one* settings file, and then the rest of the
building is done by jam itself.  Jam has three extremely nice things
about it for larger projects:

	1. You can have "if" statements, and thus avoid having to conditionally
splice together makefiles.
	
	2. You can have procedures in it, and thus you can write things like
"LinkPlugin foo" that will fill in all the individual rules necessary.
	
	3. It is easy to do non-recursive setups where the top-level Jam sees
the entire dependency tree.  Imagine being able to edit any file, type
"jam", and be convinced that the tool recompiled the correct things?

In short, I find that auto*conf* plus Jam gives me a setup where each
tool is doing a job it is good at, and where I do not spend a lot of
time learning too much arcana.  Further, I tend to actually understand
what the tools are doing; the error messages are almost all at the level
of the Jamfiles, unlike with massive autotool usage where you get lots
of errors in macro-assembled ultra-portable roundabout shell script.

Now, some people say that a problem with Jam is that it is non-standard,
but note two things.  First, GNU make is also nonstandard, and don't we
require that right now?  Second, Jam is open source and very easily
installable.  It's not "configure; make; make install", but simply
"make".



Anyway, just food for thought.  In the end, I'd love to be proven wrong,
but I expect we end up just trudging along with the solution that
already works.  Maybe the next time I'm in an argument like this, I can
point to the Squeak mailing list for an example of how overuse of
autotools and make can cause things to be hard!

-Lex