>> [T]he current [autoconf] maintainers seem to have a tendency to get
>> blinded by features in the few make programs they commonly use.
> I have nothing more to add here; I've always found GNU auto* to be
> rather a restraint to portability than an aid.

Amen.  I hate autoconf.  Or more precisely, I hate dealing with
configure scripts generated by autoconf.  For people who are willing
to roll over and accept the defaults, they doubtless work very well.
But I'm not.  And the defaults are wrong often enough, and convincing
it that I know better than it does when it guesses wrong is hard
enough, that the balance is way over on the negative side.

In particular, its idea of how things should be installed bears little
resemblance to mine.  It usually can be persuaded to do something at
least somewhat like my way, but it needs at least three or four options
for simple programs, more like six or eight for more complicated ones,
to do so.  Two- and three-hundred character "configure" command lines
are common in my build scripts for configure-using software - and I
often have post-configure patches on top of that.  And it takes me six
or eight iterations, usually taking the time for most of a full build
each time, to find all the lurking things I need to override and/or
patch to get it right.  And of course they're never documented.

> Of course, that's also because many people just write
> autoconf/make/libtool scripts with unportable assumptions.

Yes, I suppose, to be fair, I should remark that I don't know whether
this is a problem with autoconf or a problem with how autoconf is
commonly used.  I just know that when I see an install document that
says to run ./configure, my reaction is "oh hell, not _another_
friggin' "configure" script to struggle with".

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B