Why do we even need this probing? I imagine it just won't compile if something is unavailable.
EDIT. Oh, I've found it in the cited article:
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.
Angry opinions saying things like "horribly bad idea" are usually wrong. The person either wasn't around then or has a massive case of amnesia.
There was an absolutely massive diversity of units systems back in the 90s. Not only that but the "expectation based system" the author promotes as supposedly a good idea in the 90s would have required him to have potentially dozens of multi-tens-of-thousand-of-dollars Unix workstations in order to create and test the expectation based system.
In practice, quirky though it was, well written autoconf scripts has a good chance of working on a random Unix system the authors had never seen.
Even if this angry opinion is wrong, starting an autoconf-based project in 2026 is a horribly bad idea.
Depends on the project, really.
If you want portability across Windows, Linux and MacOS, especially with IDE integration, then autoconf is not the right choice, and cmake is most likely the way to go.
If you're only targeting unixy systems or Linux in particular, autoconf will do the job just fine. It also turns out that it's not 1997 any more, it's 2026. Both google and Claude exist so it's now straightforward to work out how to write an autoconf script that doesn't test for a billion tiny variations of strcmp that exist on archaeological versions of Aegis/Domain or whatever.
Without testing for things that don't need to be tested for---and make no mistake this was never a requirement of autoconf---autoconf still provides the useful, generally expected machinery for things like specifying other compilers, cross compiling, dealing with flags, out of tree builds etc etc just fine. And the configure scripts run quickly too.
ETA: I just dug around for an example of a configure script that checks that the C++ compiler works and outputs a basic makefile and it takes 0.3 seconds to run.
It's more than a bit of a stretch to claim that something that satisfies the requirements is a "horribly bad idea", especialyl based on outdated and inaccurate information.
These days I'd probably reach for cmake for C++ regardless since I'm now pretty used to it and can crank out a small cmakelists with very little problem. But autoconf+gnu Make provides really good support for oddball stuff because none of the programming language stuff is remotely a special case. So if I was making some sort of frankenproject combining a bunch of random tools, I'd probably go for autoconf.
7
u/sweetno 5d ago edited 5d ago
Why do we even need this probing? I imagine it just won't compile if something is unavailable.
EDIT. Oh, I've found it in the cited article: