GNU – the organization that keeps giving. I’ve currently got two different projects hosted on nongnu.org. All things given, it’s a lot better service than sourceforge. (Ahhh, sourceforge, home of twelve million dead projects, and a couple dozen of still useful ones.) But that’s not what I’m here to write about.
I’m here to write about the sickening pothole into hell that is autoconf. Autoconf, through some sickening joke, has managed to succeed as the #1 method of building makefiles. It’s used by all major projects, in some form or another. If it’s on GNU/Linux, it’s most likely configured by autoconf(unless we’re talking about X11, the only piece of software that makes autoconf look stylish.) But see, the funny thing is, I don’t think ANYONE quiet understands how Autoconf works outside of the three or four people that maintain it.
I would like to know for instance, why on half the projects I compile, after running configure once, and typing make, configure, for no apparent reason decides that it needs to run AGAIN. Each time running the SAME freaking tests OVER AND OVER AND OVER. I can go through half of them by memory now, from watching compile screen after compile screen after compile screen. Let me think “checking for unistd.h”, “checking whether build environment is sane”, “checking for BSD-compatible install”, and so on and so forth. One wonders if it ever occured to anyone that *maybe* this invention of a hard drive could *somehow* manage to actually store this information for later use.
But, I digress. It’s the very height of fun when installing program xyz-version 5.4.2, to sit and run through the 55,000 different options for this program. Is it –with-x today? Or –with-gtk? Or do I need to do a –enable-gnome? Oh the choices!
Of course, when things go wrong, that’s where the real fun begins. Oh no, the xyz-version 5.4.2 thinks that I have libabc installed in /usr/lib, when it’s really in /opt/kill/me/now/damn/it. Of course, the wonderful configure picked up on the fact that it exists, just not WHERE it exists. I don’t, however, know this immediately. Instead, I have to recompile the program, and redirect stderr(hint for n00bs its >&) to a file, tab through the file, and find the start of a 93 line long list of errors.
Now, if you where in this situation 5 years ago, you would know to take a quick look at the Makefile, and add a few more flags to one environment variable or another. So, you, being the seasoned Unix person you are, first go and pop up emacs(the one thing the GNU people got right), and open the Makefile, only to be suprised with a 50,000 line long monstrosity, with multiple, conflicting environment variables. Upon seeing this gateway to the seventh circle of hell,you of course, do one of the following: A. close the editor and try another piece of software, B. try to edit one of the 53 different .in, .am, .figtree, .bannana, .yoyo files that auto* uses, or C. shoot yourself in the head with a twelve gauge shotgun. Or, you could try to wade through the file, editing the 500 different $LIBS flags, all of which are completely useless except for the one three directories down called $(FOO_BAR_NONSENSE_NAME_VARIABLE), only to discover that having found the proper variable, FINALLY, running make this next time causes “configure” to rerun and trash all that hard work. Of course, you forgot to write down the file/line number or name of the variable, so you start the wonderful search all over again.
Let’s be honest. People don’t write configure.in files, they either A. use a tool to generate it, or B. copy them from someone else. What else would explain the same five errors that happen in all the programs that use autoconf. Finding documentation is even more of a challenge, you are left either purchasing a book(which will be out of date), reading an ancient howto(most of which doesn’t work properly), or wading through the even more wondrous “info” tree. It doesn’t help matters that the “info” tree seperates things out into 4 different packages, requiring you to flip from one to the other, to figure out why your configure.in is causing your makefile.am to puke when run through automake.
I’ve come to the conclusion that the auto* tools where designed by Satan himself in an attempt to drive me into a slow and deliberate madness. The sad thing is, I think it worked.
