Editing GNU Autotools (section)

==Criticism==
In his column for ''[[ACM Queue]]'', [[FreeBSD]] developer [[Poul-Henning Kamp]] criticized the GNU Build System:<ref>{{cite journal |first=Poul-Henning |last=Kamp |year=2012 |journal=ACM Queue |volume=10 |issue=8 |title=A Generation Lost in the Bazaar|pages=20–23 |doi=10.1145/2346916.2349257 |s2cid=11656592 |doi-access=free }}</ref>

{{quote|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.}}

Kamp sketches the history of the build system in the portability problems inherent in the [[History of Unix#1980s|multitude of 1980s Unix variants]], and bemoans the need for such build systems to exist:

{{quote|the 31,085 lines of configure for libtool still check if {{mono|[[stat (system call)|<sys/stat.h>]]}} and {{mono|[[C standard library|<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.}}

Although critics of the Autotools frequently advocate for alternatives that provide greater simplicity to their users, some have argued that this is not necessarily a good thing. John Calcote, author<ref>{{cite web|url=https://www.penguinrandomhouse.ca/books/600402/autotools-2nd-edition-by-john-calcote/9781593279721 |title=Autotools, 2nd Edition by John Calcote {{!}} Penguin Random House Canada |access-date=January 22, 2021}}</ref> of the ''Autotools, 2nd Edition: A Practitioner's Guide to GNU Autoconf, Automake, and Libtool'', opined:<ref>{{cite web|url=https://lists.gnu.org/archive/html/automake/2021-01/msg00013.html |title=Re: Future plans for Autotools |access-date=January 22, 2021}}</ref>

{{quote|
The Autotools are actually more transparent than any other build tools out there. All these other tools' (cmake, maven, etc) - that purport to be so much simpler because they insulate the user from the underlying details of the build process - these tool's primary failure is that this very insulation keeps users from being able to make the changes they need to accomplish their unique project-specific build goals.

Anyone who has nothing but good things to say about this aspect of cmake, maven, gradle, or whatever, has simply not worked on a project that requires them to move far enough away from the defaults. I've used them all and I've spent hours in frustration trying to determine how to work around the shortcomings of some "do-all" (except what I want) tool function. This is simply not an issue with the Autotools. As someone mentioned earlier in this thread, you can drop shell script into a configure.ac file, and make script into a Makefile.am file. That is the very definition of transparency. No other tool in existence allows this level of flexibility.}}