Autoconf discussion
Broadly online, autotools discussion boils down to:
- Autotools helps porting to weird platforms
- Autotools is useless because why do we need 20 year old checks on modern platforms
- Autotools produces thousand line shell script abominations and is therefore bad
- Build system XYZ is better
This page is a discussion around many of those ideas.
A quick aside about other languages that don't need a separate build system
Many languages don't need a separate build system from the language compilation tools. Significant examples I've used of such have been Rust, Haskell, and C#. To be clear, this is great. I believe if C and C++ should move in any direction, it would be to streamline the build systems in ways to ensure correct incremental compilation given source code analysis.
Obviously for C and C++, there are a lot of historical reasons that get in the way, but any language's tools that can look at source code and produce the output required is fantastic.
However, with enough time, almost any build system, including Autotools, CMake, Meson, SCons, or just plain Makefiles, can produce a good enough solution for most people. But, that's the thing, it takes time, and a lot of people don't want to spend time on such things (I'm weird; I do).
Autotools helps porting to weird platforms
Depending on who you are, this is invaluable. Not everyone is on a Linux distribution that might be modern or have the same filesystem hierarchy layout as another Linux system. Finding capabilities of the system's environment is quite possibly one of the most important things for a build system to do.
To me, there is a lot of value in something that's still around in 1991, not to invoke appeal to tradition. That's 35 years of problems being solved by a suite of tools that has evolved over time (with 2026 is just around the corner). However, the problems it solves today has not been solved by newer build systems (most commonly autotools is replaced by CMake). They either leave platforms behind, or require installation of that build system to run (which might have weird quirks because of an undertested platform).
That isn't to say autotools is perfect. It's not. But I do believe on an ideological basis that leaving platforms behind should be done carefully.
Autotools is useless because why do we need 20 year old checks on modern platforms
To me, this is akin to asking "Why do we need this 20 year old automated test when we haven't hit that issue in the modern day?". This might be a valid question, but it could be phrased more constructively.
There's no fundamental harm to a build system to have this in. Maybe it spends a couple seconds longer on configuration. But if the test *does* fail, it would be valuable to know (or even work around the failure as autotools can do).
Autotools produces thousand line shell script abominations and is therefore bad
"Compilers produce ten million byte executable abominations and are therefore bad". And most people who make this argument probably will be resistant to this argument, but we have several ways to compile programs to Javascript, including minifying and tree shaking, to the point they could be considered "abominations".
The shell scripts autotools produces are compilation targets, not human-readable source code. Look at the files they're generated from instead.
Build system XYZ is better
Maybe that is true, maybe it is not. I believe most build systems will work well if people put the time into them. And people tend not to put enough time into their build systems (and, I don't blame them; build systems are generally not what someone wants to deal with when they want to code).
But I, myself, am happy whenever I get to compile an autotools or autotools-like source. Being able to pass `--prefix=PATH` is fantastic. Or being able to get a list of options with `--help` like every command line program should provide is awesome.
For me, I am happy to utilize autotools if simple Makefiles are not the way to go.
(go back to home)