GNU Autotools Grievances

Part 1, of Infinity

• Adding or renaming a source file requires changing Makefile.am, which means you have to run autoreconf again, which generates a new configure script, which you then must re-run, even though nothing about your configuration has changed.
• Pulled some changes, now out of date, and you want to run make clean? Have to run ./configure again.
• Why, yes, my system has strlen. Thank you for checking. Again. And again. And again.
• Is there a sane response to C development on a system without strlen?
• NB: Folks running UNICOS don't get to vote.
• Every function, header, and library you check for in autoconf results in generating a C/C++ program and compiling, all done through shell script, natch.
• The GNU documentation advises against globbing all source files in a given directory for your Makefile and recommends, instead, listing them all individually. Who does this?
• Autoconf is really just a bunch of shell macros, which means they introduce new shell variables. So when you see a variable referenced somewhere and you search for it to find where it's set, good luck to you.
• libtool! Huh! Good God, y'all... What is it good for? Absolutely nothing!
• Seriously, this is a gigantor shell script whose purpose in life, to the best of my understanding, is to supply the right GCC options for building object code for shared libraries, and then linking them together.
• That is, it's an enormous shell script middleman to save you the hassle of knowing "-fPIC", "-shared", and ".so". No, really.
• 20 years ago (maybe even 10; maybe), the platform portability problems libtool was “designed” (a strong word for anything written in shell) to fix might have been an issue. EVERYONE USES LINUX NOW. And those who use FreeBSD still use the same tools.
• IT HIDES YOUR EXECUTABLES in .folders and generates shell scripts which you think would be your executables, but aren't, and their sole job in life is to fuxor the PATH and then invoke the hidden executables. Good luck using some debugger other than gcc.
• The configure script is not in any way parallelizable. Running it on a wide enough machine can actually make it the slowest part of building.
• Want to make a debug build? Rerun configure.
• Want to use an alternate compiler on your system? Make sure you pass CC and CXX as variables on the command-line every single time you run configure. (Props to SCons for remembering default choices in its build_variables.py file.)
• Have you ever tried reading through the phantasmagoria that is the shell scripts generated by autoconf? It's seriously the inspiration behind Plato's Allegory of the Cave.