[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: just one of a million reasons why autoconf is a worthless piece of s

From: Dan McMahill
Subject: Re: just one of a million reasons why autoconf is a worthless piece of shit (2)
Date: Tue, 18 Mar 2008 20:42:31 -0400
User-agent: Thunderbird (Windows/20080213)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]