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

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.