A new CMake Scripting Language?
Disclaimer: author of a build system that will compete against CMake when it&#x27;s released.<p>I&#x27;m not impressed, for two reasons:<p>* Backwards compatibility for the CMake language is <i>not</i> desirable. It would be better to allow files to be translated to the new language completely. Sure, CMake could support having files in the old language and files in the new language, but the CMake language is so bad that a break from it is the best path forward.<p>* The CMake language is <i>not</i> the only drawback to CMake, unlike the claims in the presentation. CMake&#x27;s model is hamstrung as well, in several ways.<p>Here are some ways in which the CMake model is hamstrung:<p>* Generating a build file for another build system. This means that CMake always gives up control of the build. It can only tell the other build system the dependency graph and then sit back and watch. It can&#x27;t regulate the build itself.<p>* No dynamic dependencies. If you need dynamic dependencies, you need to call into CMake to generate a <i>new</i> and <i>separate</i> build file for the second build system and then call that. And because the two build files that CMake generated don&#x27;t know anything about each other, it&#x27;s hard to regulate the use of computing resources between them; you either have to complete the one and start the other, or you risk over-extending on your computing resources.<p>* No way to generate a target that doesn&#x27;t call an outside process. More generally, the only way to generate a target (unless my CMake knowledge is old) is to have the second build system create a child process. This is strictly less powerful than having the same scripting language available during configure also available in targets. For example, LaTeX is only properly built with a loop that checks for a fixed point. If you can&#x27;t loop in your target, you have to use an outside bash script or something of the sort to make up for it.<p>* No way to have targets that do not generate files and have other targets depend on those targets. If a target does not generate a file, CMake does not know how to make other targets depend on it (unless my CMake knowledge is old).<p>* The model of &quot;configure in Turing complete language and then build&quot; also means that configuring often has to happen more than once before a build. You see this if you use `ccmake`: you configure, and new options appear. You set the options and configure again. More options might appear. Using plain `cmake` hides this by using defaults, but that just means the user might end up with a build they didn&#x27;t want because they didn&#x27;t get a chance to set all of the options they might care about.<p>Anyway, rant over.