Re: just one of a million reasons why autoconf is a worthless piece of shit (2)

[Dan McMahill]

Paul Smith wrote:
> Since your last post seemed to be a bit more willing to engage in a
> dialog, I'll send this then I'm done.  Some of these points have been
> made already but maybe some concrete examples will help. 

I've heard various complaints about autoconf and automake over the years 
and here are some observations I've made.

- you can write a horrible configure.ac just as you can write a horrible 
 C program.  I've seen it too many times.  One example is using the 
host triplet fed into a case statement to set a hard coded compiler name 
instead of using AC_PROG_CC.  Another example is using non-portable 
shell constructs like == instead of = in a test argument.  autoconf 
gives you the flexibility to shoot yourself in the foot, but I think a 
more restrictive approach is likely to be overly limiting.

- configure is like the output of a compiler.  Fix the input, 
configure.ac, not the output, configure.  Understand the input well 
enough to debug things there.  A common complaint I've heard is 
'configure' is too complex to debug, but those same people don't debug 
their C code by trying to parse the machine language output.

- there are lots of home grown autogen.sh scripts out there and some are 
more portable and robust than others.  The original poster on this 
thread obviously doesn't have one of the more robust ones.

- autoconf can usually help you work around bad and ugly behavior of 
other tools but not always.  Sometimes the other tool (no I'm not going 
to name 2 of my  prime offenders here) really is in need of fixing and 
instead autoconf gets blamed.

- you may think you can do better but in nearly every case I've seen 
where someone made their own build system "because autoconf sucks" it 
failed to work out of the box with even minor deviations from a vanilla 
x86 based linux box.  Also, home made build systems nearly always 
present a maintenance headache for maintainers of a package for various 
BSD or Linux packaging systems.  I'm speaking here from close to a 
decade of maintaining several packages for NetBSD's pkgsrc.  I can 
almost guarantee that a home made build system will cause me more work. 
 autoconf provides a consistent way (assuming the person who wrote 
configure.ac didn't screw it up) of setting the compiler, the linker, 
compiler flags, install directories, prefixes, etc.  It has a consistent 
way for cross compiling, building outside the source tree, setting 
various compile time options, etc.  These options get used more than 
people may think.

I can't stress the garbage in garbage out part enough though.  I've seen 
a huge number of very poorly written configure.ac scripts over the 
years.  Then again, I've seen many examples of poorly written C code too 
(64-bit dirty, big endian dirty, buffer overflows, uninitialized 
variables, etc).  Often times users equate a bad configure.ac with a 
broken autoconf which I think isn't fair.

Now, I can't claim that I've never been frustrated by autoconf or 
automake.  I have.  But so far nothing else seems to come close in terms 
of actually working for real.  Are there things which could be done 
better?  Of course.  There always will be for any tool of any complexity 
 at all.  I think the solution there is to work on improving what we 
have and not tossing it out.

-Dan