Poul-Henning Kamp's article, A Generation Lost in the Bazaar, explained the absurdity of autoconf & libtool at length. I quote some of it, below.<p>“At the bottom of the food chain, so to speak, is libtool, which tries to hide the fact that there is no standardized way to build a shared library in Unix. …the source code for devel/libtool weighs in at 414,740 lines. Half that line count is test cases… the tests elaborately explore the functionality of the complex solution for a problem that should not exist in the first place. Even more maddening is that 31,085 of those lines are in a single unreadably ugly shell script called configure. The idea is that the configure script performs approximately 200 automated tests, so that the user is not burdened with configuring libtool manually. This is a horribly bad idea, already much criticized back in the 1980s when it appeared, as it allows source code to pretend to be portable behind the veneer of the configure script, rather than actually having the quality of portability to begin with. It is a travesty that the configure idea survived. …<p>“The configure scripts back then were written by hand and did things like figure out if this was most like a BSD- or a SysV-style Unix, and then copied one or the other Makefile and maybe also a .h file into place. Later the configure scripts became more ambitious, and … rather than standardize Unix to eliminate the need for them, somebody wrote a program, autoconf, to write the configure scripts.<p>“Today's Unix/Posix-like operating systems, even including IBM's z/OS mainframe version, as seen with 1980 eyes are identical; yet the 31,085 lines of configure for libtool still check if <sys/stat.h> and <stdlib.h> exist, even though the Unixen, which lacked them, had neither sufficient memory to execute libtool nor disks big enough for its 16-MB source code.”<p><a href="http://queue.acm.org/detail.cfm?id=2349257" rel="nofollow">http://queue.acm.org/detail.cfm?id=2349257</a>