CMake is marketed heavily, but not all things which are said about autotools are accurate. Here is a video from somebody from KitWare who compares autotools to

CMake is marketed heavily, but not all things which are said about autotools are accurate. Here is a video from somebody from KitWare who compares autotools to CMake: https://youtu.be/8Ut9o4OdSC0?t=459 https://youtu.be/8Ut9o4OdSC0?t=459 In this section, he kind of complains about the number of files which are needed to use an autoconf install. But the thing is, almost all of these are generated files. So, one does not have to create them - they are created by autoconf, once, by the developer, and stored together with the rest of the source distribution for installation. Then, in the seconds after, at https://youtu.be/8Ut9o4OdSC0?t=582 https://youtu.be/8Ut9o4OdSC0?t=582 he compares the speed of autoconf to CMake, and CMake comes out faster. But, well, this time, he also adds to the total time the time which is needed to run autoconf for the first time, which generates the above files. So, in practice, a developer which changes source files, or a user which installs a package, does not need to run the autoconf generation of the configure script, and a developer which does imporovements and testing in the source code also does not need to build the configure script each time. To sum up, at the one hand side, he counts the generated autoconf files into the number of files needed for a package, but then he counts again the generation time into the run time to use autoconf regularly. And this is a bit weird, because the configure script and the other files only have to be generated once when a change to the build system is made, not for install builds and not for normal development builds. I agree that autoconf could run a tad faster and that generated files could be organized a bit tidier (it is possible to configure it so that it puts them into a subfolder). But I think the comparisonn in the video is a little bit biased. And of course, a company needs to make money and sell its products, but if a presentation of a core product starts with such a biased comparison, it is not very convincing to me. Well, we'll see where CMake is in five years time - build systems are extremely complex and large things and need to account for a lot of stuff which is rarely used to work robustly, and then it is perhaps coming to an age where things like good architecture, good design, and clean code mattes. I am not worried that CMake does not manage to do highly automated builds for simple projects and happy paths in the most popular platforms, but how it copes with the hard stuff on which a lot of computing infrastructure depends. There is a good reason why most of this infrastructure stuff, be it the kernel, or things like glibc, or OpenSSL, is not made by companies.