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

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