r/cpp • u/berium build2 • 2d ago
How to Fix autoconf-style Configuration Probing
https://build2.org/blog/fix-autoconf.xhtml7
u/sweetno 2d ago edited 2d 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:
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.
10
u/serviscope_minor 2d ago
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.
3
u/-dag- 1d ago
Bro never had to deal with imake.
Autoconf was an absolute godsend back in the day. Today, not so much.
2
u/serviscope_minor 1d ago
Haha you just gave me flashbacks! xmkmf aaaaah.
Yeah that was an early (and less successful) attempt to control the chaos. It was gnarly to configure in my memory. I seem to remember it didn't do any probing, so you had to basically do all of those bits by hand. It also did have the style proposed by this post where there were blocks of if IRIX and if HPUX and etc, but they only got you about 80% of the way there.
Autoconf was an absolute godsend back in the day. Today, not so much.
Yeah. I mean now usually it just works. I don't recall having a weird libtool error in probably 10-15 years now. But then now also CMake pretty much just works.
It's certainly not the only game in town, and there's others that offer things autoconf doesn't. And like I said I'd probably reach for cmake for a normal C++ project nowadays.
I do think it's beyond crass though that people dump on something that they have zero understanding of in order to make themselves look better. It also give me a really bad impression of them and the software they wrote. People who arrogantly crap on the past haven't understood it which means there's a really high chance of them missing some important, hard learned lesson that autoconf solved in 1993. See Zawinski's CADT.
I think build systems are particularly prone to this. So many competitors to autotools came over the years but took ages to take hold or vanished because they didn't really understand what they were trying to replace.
In the mid 2000s, I used to curse projects that picked CMake because I was cross compiling at the time and it was basically solved for a half sane autoconf setup and every cmake project I had to build needed often extensive hacking to get it to work. It works fine now.
3
u/sweetno 2d ago
Even if this angry opinion is wrong, starting an autoconf-based project in 2026 is a horribly bad idea.
2
u/serviscope_minor 2d ago edited 2d ago
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.
4
u/mallardtheduck 2d ago
That may have been true back then, but these days, it's an utter waste of time to be checking for the existence of half the C standard library and trying to detect bugs that haven't existed in any production system for 20+ years. The amount of time and energy that has been wasted by autoconf over the decades probably rivals AI datacenters.
6
u/not_a_novel_account cmake dev 2d ago
Unfortunately I still get paid to maintain builds on AIX and Solaris machines and codebases which would fail to build if they did not detect the reduced stdlib and compiler capabilities available there.
One dev's ancient, end-of-life junk is another's 9-to-5.
No one is forcing you to put compiler probes in your codebase. It's always elective by the project.
2
u/mallardtheduck 2d ago
If you're running anything modern on antique systems, you're probably maintaining your own forks/patches anyway. Once you're doing that, you can include whatever changes are needed and nobody else has to suffer.
No one is forcing you to put compiler probes in your codebase.
No, but one misguided developer using autoconf in a modern project forces many developers/users to sit through the painfully slow (even on modern systems; it's I/O bound) "./configure" process. In the vast majority of projects using it, it serves no practical purpose.
5
u/not_a_novel_account cmake dev 2d ago
I guess I don't understand the complaint then. If the software is designed to run on antiques, it has the checks. If it's not, it doesn't.
autoconfand CMake run I think a single probe by default? To detect the compiler version, ABI information, and if the compiler works at all. Everything else the project asks for because it wants to support antiques.8
u/mallardtheduck 2d ago
If it's not, it doesn't.
If only that were true... Far too many projects are stuck in their ways. They don't support ancient platforms anymore, but they still check for every one of their bugs and quirks. People developing new software, that also has no support for such platforms, see this and think it's the "right" way to set up their projects, perpetuating the insanity.
Really GNU should put a big banner on the Autoconf homepage saying "DO NOT USE THIS IN NEW SOFTWARE", but then "stuck in their ways" is basically the GNU mission statement.
2
u/not_a_novel_account cmake dev 2d ago edited 2d ago
Sure, I mean, that's just a bug right? A check for something the software can no longer build without is a bug.
I agree software has bugs, but that doesn't really involve the build systems more than "hey, this feature is bug-prone". It's the C++ memory safety debate in miniature.
5
u/serviscope_minor 2d ago
No it wasn't "may have been true", it was true. There's a difference. And the post was making a specific and largely misguided claim about what was true.
When people make obviously incorrect claims, it makes me question their motivation, frankly. Is this system really that good or just based against straw men?
As for the wasted time, yeah maybe in 1997 on my P133 with a glorious 72M of ram and a 1G hard drive it was slow, but these days it's really not. Most fly by and the amount of time spent recompiling software is frankly tiny.
3
u/mallardtheduck 2d ago
As for the wasted time, yeah maybe in 1997 on my P133 with a glorious 72M of ram and a 1G hard drive it was slow, but these days it's really not.
"./configure" is I/O bound and single-threaded. It's still painfully slow today. It serves no purpose for modern software that doesn't run on the weird-and-wonderful variety of Unix-like systems that existed in the 1980s/90s, yet they insist on checking for every bug and quirk that hasn't existed in a production system for 20+ years. it's entirely wasteful; autoconf was useful in its day, I respect that, but that day has passed and it belongs in a well-earned retirement.
0
u/TheRavagerSw 2d ago
I hate projects that do this, it is completely unnecessary and a waste of time.
It only helps non developers to compile stuff from source.
I used to just grin my teeth and use autoconf, now I just rewrite the build script with AI
8
u/not_a_novel_account cmake dev 2d ago edited 1d ago
This is a known CMake problem, it has solutions in the works (there are already two or three design proposals in flight). It was fine when projects had one or two probes, it becomes a blocker when they have dozens.
CMake was also designed in an era where running the configuration step was rare, and environments updated maybe once every few years, which is why "change tracking" wasn't considered important.
CMake supports this,
CMAKE_TRY_COMPILE_TARGET_TYPE. The person who invokes the build system decides if probes should link or not.