I dearly regret that I adopted autotools for some of my projects. As TFA identifies, the primary problem autotools solved is no longer a problem: Linux, BSD, Darwin, and Cygwin are the targets today and they're more-or-less portable and compliant. Meanwhile, autotools is a constant tax on the development cycle.
1. autoconf is awful to learn.
2. autoconf can be useful in determining the platform, dealing with a few quirks, and ensuring that system dependencies/libraries are satisfied.
3. autoconf's usefulness here is completely undermined by automake, as changing Makefile.am requires rerunning autoreconf, which then requires rerunning configure. So, developers must constantly rerun the configure script, even though nothing about their system environment has materially changed. For example, this happens when a new source file is created and added to Makefile.am.
4. Perhaps the most egregious missing weakness from TFA is acknowledgement that configure scripts are horrifically slow. It's 2022 and developers have their time wasted by configure checking whether printf() exists.
5. automake documentation discourages developers from globbing source files in source directories, and insists they list them individually. It's silly and just results in needless running of configure.
6. The complex interdependencies between generated files is nigh-impossible to understand and reason about. It's cruft.
7. libtool is completely braindead, the absolute worst of it all. It serves absolutely no purpose on contemporary systems, but the docs continue to admonish developers that they must use it to stand a chance of creating a shared library (no, just learn to specify -fPIC). Instead of analyzing a project once, as part of autoconf, libtool determines what to do on the fly for every source file--and all in bash. It doubles a project's compilation time.
8. Creating alternatives to libtool with new autoconf macros, deprecating libtool, and cleansing all traces of it from the planet should absolutely be the highest priority of the autotools project.
> 4. Perhaps the most egregious missing weakness from TFA is acknowledgement that configure scripts are horrifically slow. It's 2022 and developers have their time wasted by configure checking whether printf() exists.
I'd say on some platforms "horrifically slow" is an understatement. At my day job we were building software in Cygwin on Windows machines infected with Symantec's virus scanner which adds hundreds of milliseconds to every process launch. The configure script for Protocol Buffers took something like half an hour to run.
We eventually switched to CMake but not without a lot of pain first. For what it's worth, CMake fixes the speed issue but not much else. It still has its own totally esoteric custom language, it still discourages globbing source files and requires re-running upon adding any file or changing anything, and it has even more insane default settings than autotools (for example file(DOWNLOAD) from an https:// URL by default ignores certificates!)
There is something wrong with all of these buildsystems. I don't know what the solution is but I feel we are very far from it.