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
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
