It's already bad enough that the developer needs to understand both target-based CMake and legacy CMake, now there need to be two more languages (slide 13) that must be understood? It's been 9 years since Modern CMake came out, and I'd estimate adoption at 50-50.
This deck does not address the drawbacks of doing this at all, and the only recognition of this problem is in "Stretch Goal: Research development of tool(s) to translate legacy CMake to new CMake language."
The current CMake language is fine. Nothing amazing, but good enough.
But every moment that I spend configuring CMake is a moment I don't spend doing something actually useful. I don't want to disparage the team's work--CMake is awesome software--but the way they see it is very different from the way typical developers see it.
> The current CMake language is fine. Nothing amazing, but good enough.
Lol CMake was a huge reason I got out of C++ development almost a decade ago. I was tired of scripting my own shitty build systems, especially ones which couldn't even manage packages. I never actually need the power CMake offers, but the stuff I do need (reproducible package management) CMake punted on. 99.9% of the time, all you need is a build tool that takes a list of dependencies and a lockfile (or similar).
> It's already bad enough that the developer needs to understand both target-based CMake and legacy CMake (...)
No. "Legacy cmake" has been made obsolete with the release of cmake 3.0, almost a decade ago. There is absolutely no excuse to use anything other than the declarative, target-based "modern cmake" style.
I'd go as far as claiming that 95% of all use cases boil down to simple straight-forward one-liners with modern cmake, with the remaining 5% corresponding to putting together custom cmake find modules, packaging, and deploying runtime dependencies.
> (...) now there need to be two more languages (slide 13) (...)
I'd argue that if anyone feels the need to write scripts to do something in cmake, they are already doing something awfully wrong to start with.
> It's been 9 years since Modern CMake came out, and I'd estimate adoption at 50-50.
> The current CMake language is fine. Nothing amazing, but good enough.
I'd argue these two statements are in conflict.
I came to c/c++ after several other languages and ecosystems -- the c++ dependency/build ecosystem is by far the worst.
CMake does work. It's underlying capabilities are great, even. But "modern cmake" is sort of a joke syntactically. Generator expressions are indecipherable. Semicolon delimited arrays, no distinguishing between input/output variables... I personally would love for a different DSL frontend to CMake.
> I don't want to disparage the team's work--CMake is awesome software--but the way they see it is very different from the way typical developers see it.
I have to agree with this. The underlying core of cmake is actually pretty awesome. Modern cmake is an improvement in capability. The team deserves credit for that.
The absolutely atrocious current cmake language (where you can't even make a list of strings! The ONE THING a make replacement should fix!), in combination with the prevalence of legacy cmake everywhere (even in Find*.cmake files distributed by cmake!), are the two primary reasons why I'm using and rooting for Meson over CMake.
But its biggest issue, arguably, is the extreme proliferation of bad information. Everything on StackOverflow and similar sites is outdated and bad practice for the most part. You're right that introducing a new language which deprecates the old will make this an even bigger issue.
I just don't get the hype around make/CMake/autotools. I usually implement the build tool in the language I am working on (build.py for Python, etc.). It seems that Zig[1] also follows this.
I spent several years creating and maintaining a large, proprietary build system for a Linux-based operating system at a previous gig. Much of userspace was C/C++, and thus used CMake. To further complicate things, most of userspace needed to be cross-compilable for a macOS-based "simulator" environment.
I ended up being fairly proficient with the "modern" CMake language after investing a ton of time into it, but as the size of the company grew, I ended up being a bottleneck. Every other team found themselves subject to CMake's many footguns, and I'd end up having to step in to help.
It was maddening, but I 100% get that other teams just wanted to focus on getting their work done, rather than fighting with a poorly-documented and frustrating build system.
I, for one, would be very happy to see a new CMake scripting language. Ideally, one that is a lot more friendly for beginners and occasional users.
> I 100% get that other teams just wanted to focus on getting their work done
Getting your project to build properly should be part of "getting the work done". Modern software is way too much about stacking up hacks to "get the work done" instead of writing proper code.
Sure, there could be a better way than CMake. But it's not that hard to learn the basics.
These initiatives are quite bluntly idiotic. CMake's scripting language is a collosal red herring. CMake's scripting language is good enough for all conceivable use cases, and if you feel the need to write scripts, let alone complex ones, then you're already doing something awfully wrong and you should just reach out to the documentation to learn how to do things properly.
My recent gripe with CMake: the language toolchain is still a singleton. You can't easily use multiple C++ compilers in the same build. This doesn't feel like a language limitation.
I also never got why we need DSLs for build systems. It seems like Turing completeness is often inevitable, no matter if people don't like it. There is no reason that a build file couldn't be mostly declarative with a general-purpose programming language though.
> the language toolchain is still a singleton. You can't easily use multiple C++ compilers in the same build. This doesn't feel like a language limitation
If you're still struggling with this, a solution is to use ExternalProject to create a "superbuild" top level project that has various subprojects being built with different toolchains.
> I also never got why we need DSLs for build systems
The same reason they show up anywhere: to have the correct level of abstraction, or its cousin "signal/noise ratio." Trying to debug "gcc -o build build.cc && ./build" sounds like the 8th circle of hell to me. I can show a concrete example: https://github.com/facebook/sapling/blob/0.1.20221201-095354... So, when this raises OSError or FileNotFoundError due to some botched assumption, I guess one just attaches pdb to it and now your job is to be a python expert
All of those are in a general purpose programming language, and they require spelunking through thousands of lines of code to surface the actual commands and dependencies that are buried therein. And, if you become a domain expert in mach, where else are you going to apply that expertise?
The slide deck seems like a pitch for more funding to create a CMake replacement, rather than a description of that replacement, right? It ends with "A $1M+ investment in a new CMake language(s) and translation tools could avoid a future massively expensive transition of ASC [Advanced Simulation and Computing, at Sandia National labes] codes to another tool like Meson that could easily cost more than $10M across the ASC program and negatively impact developer productivity while the transition is taking place."
I'm curious: is there any way to estimate how much US taxpayer support went into creating CMake? Would CMake exist were it not for the DOE and/or NSF grants that Kitware got?
Getting that kind of support isn't a fault of CMake, but I think it's a meaningful property in considering and comparing different software development projects, and evaluating their long-term health.
Disclaimer: author of a build system that will compete against CMake when it's released.
I'm not impressed, for two reasons:
* Backwards compatibility for the CMake language is not 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.
* The CMake language is not the only drawback to CMake, unlike the claims in the presentation. CMake's model is hamstrung as well, in several ways.
Here are some ways in which the CMake model is hamstrung:
* 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't regulate the build itself.
* No dynamic dependencies. If you need dynamic dependencies, you need to call into CMake to generate a new and separate build file for the second build system and then call that. And because the two build files that CMake generated don't know anything about each other, it'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.
* No way to generate a target that doesn'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't loop in your target, you have to use an outside bash script or something of the sort to make up for it.
* 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).
* The model of "configure in Turing complete language and then build" 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't want because they didn't get a chance to set all of the options they might care about.
> Here are some ways in which the CMake model is hamstrung... generating a build file for another build system
That's the critical selling point of CMake in my estimation. When I'm on Windows, I can generate a Visual Studio project and use its excellent debugger and code analysis tools. When I'm on Mac, I can generate an XCode project. Or a CLion project, or Makefiles, or...
Decoupling the build "recipe" from the build toolchain is critical for collaborative, cross-platform, cross-architecture projects, IMHO.
> No way to have targets that do not generate files and have other targets depend on those targets.
> 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't regulate the build itself.
That is a hard requirement to using Visual Studio and XCode, which I wager account for more than 90% of C/C++ projects.
Doesn't Bazel / Buck do a better job? The only downside might be IDE integration outside of Google / Facebook but I think there's effective polyfills that generate compile_commands.json.
I don’t understand why people are surprised to see similar complexity creep in the “reborn” CMake ecosystem.
There has never been a one size fits all all purpose glue. It’s not surprising to me that neither is it possible to make a one size fits all “glue my software together” stack.
Well it seems on topic to bring up xmake. It has no DSL, just Lua. Been using for a year (with Cpp. Haven't tried other languages with it yet) and I love it
I recently had the need to propose a build tool. Naturally make came to my mind then I looked into something more modern. I didn't dive deep but I was left with impression that CMake and many others support a certain set of programming languages?
PS: I know that make has many shortcuts to compile a C/C++ codebase but in essence its targets as file system time stamps.
This article is discussing the scripting language of CMake (the code that describes the build) not the program that it builds.
But to your question, the answer is kinda. There is support for a few other languages built in (off the top of my head, Ada and Fortran I believe) and you can provide a custom backend as well for your own language support but most people just use add_external_command
downvoted, i mean what did i expect on a discussion about the idea to add a scripting language on top of a scripting language that is used to generate a script in an other scripting language
It's 2022. Why would I learn even more horrible CMake instead of just going full Meson? Looks like it's the same cognitive cost, but no gains by staying on CMake.
For my curiosity, does Meson emit "native" build files, such as Visual Studio, Makefiles, Ninja, or the like?
That's been my favorite part of CMake (even before CLion used it as their defacto project format): if you can get a run of cmake to complete (which, granted ...), then you can open the project in a sane IDE and have library and build targets available
[+] [-] flaviut|3 years ago|reply
This deck does not address the drawbacks of doing this at all, and the only recognition of this problem is in "Stretch Goal: Research development of tool(s) to translate legacy CMake to new CMake language."
The current CMake language is fine. Nothing amazing, but good enough.
But every moment that I spend configuring CMake is a moment I don't spend doing something actually useful. I don't want to disparage the team's work--CMake is awesome software--but the way they see it is very different from the way typical developers see it.
[+] [-] throwaway894345|3 years ago|reply
Lol CMake was a huge reason I got out of C++ development almost a decade ago. I was tired of scripting my own shitty build systems, especially ones which couldn't even manage packages. I never actually need the power CMake offers, but the stuff I do need (reproducible package management) CMake punted on. 99.9% of the time, all you need is a build tool that takes a list of dependencies and a lockfile (or similar).
[+] [-] simplotek|3 years ago|reply
No. "Legacy cmake" has been made obsolete with the release of cmake 3.0, almost a decade ago. There is absolutely no excuse to use anything other than the declarative, target-based "modern cmake" style.
I'd go as far as claiming that 95% of all use cases boil down to simple straight-forward one-liners with modern cmake, with the remaining 5% corresponding to putting together custom cmake find modules, packaging, and deploying runtime dependencies.
> (...) now there need to be two more languages (slide 13) (...)
I'd argue that if anyone feels the need to write scripts to do something in cmake, they are already doing something awfully wrong to start with.
[+] [-] chrsig|3 years ago|reply
> The current CMake language is fine. Nothing amazing, but good enough.
I'd argue these two statements are in conflict.
I came to c/c++ after several other languages and ecosystems -- the c++ dependency/build ecosystem is by far the worst.
CMake does work. It's underlying capabilities are great, even. But "modern cmake" is sort of a joke syntactically. Generator expressions are indecipherable. Semicolon delimited arrays, no distinguishing between input/output variables... I personally would love for a different DSL frontend to CMake.
> I don't want to disparage the team's work--CMake is awesome software--but the way they see it is very different from the way typical developers see it.
I have to agree with this. The underlying core of cmake is actually pretty awesome. Modern cmake is an improvement in capability. The team deserves credit for that.
[+] [-] mort96|3 years ago|reply
But its biggest issue, arguably, is the extreme proliferation of bad information. Everything on StackOverflow and similar sites is outdated and bad practice for the most part. You're right that introducing a new language which deprecates the old will make this an even bigger issue.
[+] [-] tsss|3 years ago|reply
No, CMake is terrible. It is in fact quite a feat how god damn terrible it manages to be.
[+] [-] StreamBright|3 years ago|reply
What am I missing?
1. https://ziglearn.org/chapter-3/
[+] [-] liquidify|3 years ago|reply
[+] [-] cjk|3 years ago|reply
I ended up being fairly proficient with the "modern" CMake language after investing a ton of time into it, but as the size of the company grew, I ended up being a bottleneck. Every other team found themselves subject to CMake's many footguns, and I'd end up having to step in to help.
It was maddening, but I 100% get that other teams just wanted to focus on getting their work done, rather than fighting with a poorly-documented and frustrating build system.
I, for one, would be very happy to see a new CMake scripting language. Ideally, one that is a lot more friendly for beginners and occasional users.
[+] [-] palata|3 years ago|reply
Getting your project to build properly should be part of "getting the work done". Modern software is way too much about stacking up hacks to "get the work done" instead of writing proper code.
Sure, there could be a better way than CMake. But it's not that hard to learn the basics.
[+] [-] simplotek|3 years ago|reply
[+] [-] planede|3 years ago|reply
I also never got why we need DSLs for build systems. It seems like Turing completeness is often inevitable, no matter if people don't like it. There is no reason that a build file couldn't be mostly declarative with a general-purpose programming language though.
[+] [-] matthews2|3 years ago|reply
If you're still struggling with this, a solution is to use ExternalProject to create a "superbuild" top level project that has various subprojects being built with different toolchains.
[+] [-] mdaniel|3 years ago|reply
The same reason they show up anywhere: to have the correct level of abstraction, or its cousin "signal/noise ratio." Trying to debug "gcc -o build build.cc && ./build" sounds like the 8th circle of hell to me. I can show a concrete example: https://github.com/facebook/sapling/blob/0.1.20221201-095354... So, when this raises OSError or FileNotFoundError due to some botched assumption, I guess one just attaches pdb to it and now your job is to be a python expert
Or, my other favorite "what is wrong with you:" https://hg.mozilla.org/mozilla-central/file/FIREFOX_NIGHTLY_...
Or, so as to not just be hating on python, this junk: https://github.com/brave/brave-browser/blob/v1.48.33/package... and its https://github.com/brave/brave-core/blob/master/build/comman... friend
All of those are in a general purpose programming language, and they require spelunking through thousands of lines of code to surface the actual commands and dependencies that are buried therein. And, if you become a domain expert in mach, where else are you going to apply that expertise?
[+] [-] an1sotropy|3 years ago|reply
I'm curious: is there any way to estimate how much US taxpayer support went into creating CMake? Would CMake exist were it not for the DOE and/or NSF grants that Kitware got?
Getting that kind of support isn't a fault of CMake, but I think it's a meaningful property in considering and comparing different software development projects, and evaluating their long-term health.
[+] [-] marwis|3 years ago|reply
[+] [-] ghoward|3 years ago|reply
I'm not impressed, for two reasons:
* Backwards compatibility for the CMake language is not 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.
* The CMake language is not the only drawback to CMake, unlike the claims in the presentation. CMake's model is hamstrung as well, in several ways.
Here are some ways in which the CMake model is hamstrung:
* 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't regulate the build itself.
* No dynamic dependencies. If you need dynamic dependencies, you need to call into CMake to generate a new and separate build file for the second build system and then call that. And because the two build files that CMake generated don't know anything about each other, it'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.
* No way to generate a target that doesn'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't loop in your target, you have to use an outside bash script or something of the sort to make up for it.
* 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).
* The model of "configure in Turing complete language and then build" 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't want because they didn't get a chance to set all of the options they might care about.
Anyway, rant over.
[+] [-] dlivingston|3 years ago|reply
That's the critical selling point of CMake in my estimation. When I'm on Windows, I can generate a Visual Studio project and use its excellent debugger and code analysis tools. When I'm on Mac, I can generate an XCode project. Or a CLion project, or Makefiles, or...
Decoupling the build "recipe" from the build toolchain is critical for collaborative, cross-platform, cross-architecture projects, IMHO.
> No way to have targets that do not generate files and have other targets depend on those targets.
Isn't that exactly what an INTERFACE library is for? <https://cmake.org/cmake/help/latest/command/add_library.html...>
[+] [-] Asooka|3 years ago|reply
That is a hard requirement to using Visual Studio and XCode, which I wager account for more than 90% of C/C++ projects.
[+] [-] substation13|3 years ago|reply
Anyway, CMake is terrible - for all the reasons you have identified - so I wish you luck!
[+] [-] ThouYS|3 years ago|reply
[+] [-] TillE|3 years ago|reply
With CMake, the new stuff still sucks.
[+] [-] vlovich123|3 years ago|reply
[+] [-] xigoi|3 years ago|reply
For me, Nim and Nimble work pretty well.
[+] [-] travisgriggs|3 years ago|reply
I don’t understand why people are surprised to see similar complexity creep in the “reborn” CMake ecosystem.
There has never been a one size fits all all purpose glue. It’s not surprising to me that neither is it possible to make a one size fits all “glue my software together” stack.
[+] [-] arberx|3 years ago|reply
[+] [-] dale_glass|3 years ago|reply
Plus the idea seems to be to add it on top, so if it flops, no big deal, the old stuff will still be there.
[+] [-] marwis|3 years ago|reply
https://wiki.netbsd.org/tutorials/bsd_make/#index1h2 https://crufty.net/help/sjg/bmake.html
[+] [-] cassepipe|3 years ago|reply
xmake.io
[+] [-] bmh|3 years ago|reply
[+] [-] chrsig|3 years ago|reply
[+] [-] actionfromafar|3 years ago|reply
[+] [-] jhoechtl|3 years ago|reply
PS: I know that make has many shortcuts to compile a C/C++ codebase but in essence its targets as file system time stamps.
[+] [-] duped|3 years ago|reply
But to your question, the answer is kinda. There is support for a few other languages built in (off the top of my head, Ada and Fortran I believe) and you can provide a custom backend as well for your own language support but most people just use add_external_command
[+] [-] samlittlewood|3 years ago|reply
[+] [-] Kukumber|3 years ago|reply
There are much better alternatives:
https://xmake.io/
[+] [-] Kukumber|3 years ago|reply
c++ is doomed
[+] [-] desiderantes|3 years ago|reply
[+] [-] Callistorr|3 years ago|reply
[+] [-] mdaniel|3 years ago|reply
That's been my favorite part of CMake (even before CLion used it as their defacto project format): if you can get a run of cmake to complete (which, granted ...), then you can open the project in a sane IDE and have library and build targets available