The bulk of the material on the web concerning GNU autotools, from libtool up through automake and autoconf, concern the brokenness of the system. I hold that this system for producing spaghetti is intrinsically harmful to software development progress.

The autotools, by design, produce incomprehensible, misleadingly indented, highly redundant code which has to be reverse-engineered in order to trade bugs back to their source in unrelated, often not even co-located files. They operate using obsolete unix artifacts (m4 to be specific) and introduce uncontrolled dependencies into the toolchain. The complexity of the autotools is far, far in excess of the complexity of simply producing portable makefiles in the first place. The cost of entry, for a potential contributor to a software project is raised prohibitively high by the use of autotools, because in order to fix a broken config, it no longer suffices to fix the error at the site where it occurs, but rather the contributor must first become a competent engineer of autotools internals, must then reverse-engineer the code-generation path for the code which failed, and then make configuration changes, which are always much more controversial politically and difficult to validate technically than are code changes.

It is not, in general, possible to determine by walk-through inspection whether an autotools configuration change will break builds on other platforms. This is because there is a combinatorial explosion in the code paths executed to perform a build, which is no longer abstracted away from the platform environment by a well-defined and crisp interface such as gmake, but rather is deeply intertwingled with the distribution architecture and implementation details.

GNU Autotools: Just say FU!