4 ms·

There's been a relatively comprehensive take-down on autoconf (1), that boils down to: It's an old piece of software, with basically no maintainers, which is f

There's been a relatively comprehensive take-down on autoconf (1), that boils down to: It's an old piece of software, with basically no maintainers, which is fantastically difficult to make any changes to. Not... stable because it "just works"; unchanging because it's so enormously complex to make and coordinate even trivial changes, that it is effectively the peak of the software lifecycle, where something has accumulated so much technical debt you can no longer make changes to it. ...so; in that context, being a fan of some features that autoconf supports is interesting, but, makes absolutely no difference to the reality; that it needs to die in a fire and be replaced. Software, that you cannot change, is dead. Especially a build tool, that has failed to be maintained to changing needs of developers. If autoconf wants to live, people need a comprehensive plan to maintain it, not to sing praises of its current, clearly bad, state. > it has been popular to suggest that Autoconf should go away. Yes. ...because no one has a plan to maintain it or fix it. > Some of the people suggesting this have also been proposing that the replacement for Autoconf and the 'configure' scripts it generates be something simpler. Specifically who? Build systems are hard. No one serious, who understands what they're talking about and the context around it that I've seen is suggesting this. ...most people, seem to consistently be suggesting that the current state of autoconf is unsustainable, and as it stands, increasingly likely to be replaced by something else; for example, cmake. ...and, goooooodness me, anyone who thinks cmake is 'simpler' has not ever had to fight it. Where is this coming from? Could it be from the author, who posts (2): > New projects today often opt for one of the existing alternative build systems and (I believe) often find them simpler. ... This is a weird set of interlinked self referential blog posts. [1] - https://www.owlfolio.org/development/autoconf-swot/ https://www.owlfolio.org/development/autoconf-swot/ discussed at least 4 times here on HN in different threads. Use the search bar. [2] - https://utcc.utoronto.ca/~cks/space/blog/programming/AutoconfNotReplaceable https://utcc.utoronto.ca/~cks/space/blog/programming/Autocon...

rleigh 2y ago
They don't really define "complexity" well enough. CMake is more complex internally than the autotools in terms of the functionality available and the internal implementation details. But it does much, much more than the Autotools ever attempted. However, the user configuration is simpler and more powerful, and the generated build logic is simpler and more flexible in terms of the output formats available. And it only requires learning a single language, not three or four. You're absolutely spot on with regard to its maintainability though. The Autoconf macros can't be changed without breaking everyone, so it's effectively impossible to change it, and we've seen that stagnation for well over a decade at this point. The use of m4 adds a whole heap of incidental complexity and inflexibility. You can never replace m4, because of the huge number of Autoconf functions internally-expanding user-provided macros. I'm unsure why they make such a big deal of configurable install prefixes and system feature testing. While Autoconf may have pioneered this, or at least popularised it, it's not like the alternative systems like CMake don't implement the exact same features. They do, though with slightly changed names (just cosmetic). Where I think they have a point, is in the huge investment into the Autotools by projects and the inertia that creates to resist change. That's very real. However, I do think that the cost of change is often overestimated. Off the top of my head, I've converted four open-source Autotools-based projects to use CMake (schroot, libTIFF, Apache Xerces-C++ and Apache Xalan-C++). Some of these had very complex logic encoded in their configure scripts; some of them had libraries of Autoconf macros to do custom feature testing. And yet, while rewriting this logic to use the CMake equivalents was tedious, it was entirely doable, and in all cases it was doable in under a week with a bit of shakedown afterwards to eliminate subtle behaviour differences. For two of these (libTIFF and Xerces), the projects maintain both systems in parallel to this day. The inertia will keep a lot of established projects using the Autotools for several more years I would expect. If it works, the incentive to change is not going to be there until the Autotools bitrot to the extent that they break with contemporary toolchains. It will happen at some point. We already see it occasionally with libtool, and I've already seen the Autotools builds I maintain fail on Solaris, Cygwin and MinGW where they worked without any special effort with CMake. Every piece of software is a child of its time. The Autotools were created to solve Unix portability problems of the '90s, and they served that purpose well using the portable and commonly-available tools of that time. However, while these tools continue to work today, they have not evolved to solve contemporary problems and that is why they aren't going to be a good choice for new projects. It will die by attrition if nothing else.

rleigh 2y ago

They don't really define "complexity" well enough. CMake is more complex internally than the autotools in terms of the functionality available and the internal implementation details. But it does much, much more than the Autotools ever attempted. However, the user configuration is simpler and more powerful, and the generated build logic is simpler and more flexible in terms of the output formats available. And it only requires learning a single language, not three or four. You're absolutely spot on with regard to its maintainability though. The Autoconf macros can't be changed without breaking everyone, so it's effectively impossible to change it, and we've seen that stagnation for well over a decade at this point. The use of m4 adds a whole heap of incidental complexity and inflexibility. You can never replace m4, because of the huge number of Autoconf functions internally-expanding user-provided macros. I'm unsure why they make such a big deal of configurable install prefixes and system feature testing. While Autoconf may have pioneered this, or at least popularised it, it's not like the alternative systems like CMake don't implement the exact same features. They do, though with slightly changed names (just cosmetic). Where I think they have a point, is in the huge investment into the Autotools by projects and the inertia that creates to resist change. That's very real. However, I do think that the cost of change is often overestimated. Off the top of my head, I've converted four open-source Autotools-based projects to use CMake (schroot, libTIFF, Apache Xerces-C++ and Apache Xalan-C++). Some of these had very complex logic encoded in their configure scripts; some of them had libraries of Autoconf macros to do custom feature testing. And yet, while rewriting this logic to use the CMake equivalents was tedious, it was entirely doable, and in all cases it was doable in under a week with a bit of shakedown afterwards to eliminate subtle behaviour differences. For two of these (libTIFF and Xerces), the projects maintain both systems in parallel to this day. The inertia will keep a lot of established projects using the Autotools for several more years I would expect. If it works, the incentive to change is not going to be there until the Autotools bitrot to the extent that they break with contemporary toolchains. It will happen at some point. We already see it occasionally with libtool, and I've already seen the Autotools builds I maintain fail on Solaris, Cygwin and MinGW where they worked without any special effort with CMake. Every piece of software is a child of its time. The Autotools were created to solve Unix portability problems of the '90s, and they served that purpose well using the portable and commonly-available tools of that time. However, while these tools continue to work today, they have not evolved to solve contemporary problems and that is why they aren't going to be a good choice for new projects. It will die by attrition if nothing else.