5 ms·

Why has it been so hard to displace CMake?

misnome 5y ago
I think a combination of - CMake has been around a _long_ time now, anything is slow to adopt in the C++ system, and people (rightly or wrongly) expect their build systems to be somewhat arcane - whilst CMake is in many cases magnitudes simpler and more portable than plain Makefiles/autoconf. In short, I think it's hard-won, and hard to let go of. Edit to add: Also, the "generates project files in multiple flavors/IDE format" makes it a very easy to sell as a path of migration, rather than a complete change.
- bch 5y ago
  Are you talking about cmake-generators(7)?
  - misnome 5y ago
    Yes. Although I don't use them much myself (outside of Make/Ninja), I still think it is a big "Plus" when evaluating build systems next to each other.
danachow 5y ago
CMake has gotten better over the years. First line support in CLion is a thing.
- pjmlp 5y ago
  QtCreator and Visual Studio as well.
BBC-vs-neolibs 5y ago
What should we replace MSBuild with? CMake is on the table. We have a lot of MSbuild files, including and calling each other.
- siwatanejo 5y ago
  Why replace MSBuild?
jcelerier 5y ago
One of my main use cases for CMake is that it works very well as a Windows, Mac, Linux cross-platform busybox. It allows to download files from the internet, unzip / untar, compute SHA hashes, do file system operations, ... in a very shell-like way (https://cmake.org/cmake/help/v3.21/manual/cmake.1.html#run-a-command-line-tool https://cmake.org/cmake/help/v3.21/manual/cmake.1.html#run-a...). It's also been very useful in allowing to implement simple code parsing and generation thanks to its regex support, without having to install Perl (a pain on Win32), Bash (a pain on Win32), Python (same) and without requiring to build another binary doing the code parsing / code generation step (which generally causes a ton of problems as soon as you want to cross-compile since the code generation binary should be built with the host toolset - e.g. what if I want to run a code generator for a WASM target or some kind of VM as part of my build and don't want to have to run multiple build passes ?). Finally I like that I don't have to put all my strings in "" unlike other build systems, I find it much more readable. The Qt GUI has also been a very appreciated features of some of my users who: - want to build of my software on their machine - are technical enough to follow instructions on a GUI - are not technical enough to use a terminal which, from my experience, is a surprisingly large amount of people.
kcb 5y ago
Because worse that any current build system is having to learn and migrate to a new one.
stormbrew 5y ago
Honestly? Because cmake is actually really good. In spite of being very hampered by a bad bespoke programming language tacked on to its model, it does most of the things a meta-build system needs to do and it does them well, and it does them without needing java or python or basically a TSR server component running in the background to make it fast.
- RScholar 5y ago
  I think a lot of that can be chalked up to the fact that the minds behind CMake are pretty consistently top-notch--most of the Kitware folks have at least one post-grad CS degree and have not insignificant levels of experience approaching design problems from a more abstract/academic POV than your average dev team. I think over the years it's kept them from making the truly awful implementation blunders that send projects scrambling for another alternative just to 'never have to do THAT again.' Hence, CMake has had the time to seep into the way projects organize themselves in ways the "flavor of the month" build systems (qmake, scons, et al.) couldn't. What I'd like to know is where this supposedly excellent documentation for Meson is that the author refers to. The times that I've needed to use Meson have been uniformly unpleasant precisely because I found the official docs to have a ton of holes and also assumed an unrealistic level of familiarity with their underlying logic. Give me the CMake docs anyday; at least I can be relatively sure the answer's in there instead of hiding in a GitHub issue regarding some design flaw that'll be solved in the next release.
- dynamite-ready 5y ago
  I'm somewhat new to using C++ often enough to care about this. At times, it genuinely feels harder to link a project, than write the code. Having come from a webdev background, where well publicised package managers have effectively directed how a project should be built, C++'s ecosystem looks to have created the opposite situation, where the utility of a project or library appears to dictate which build manager is used, in most cases. Either you go with the grain and adopt your chosen library/environment's build system, or you increase the work you have to do. I liked GYP a lot, and when starting out, was trying to stick with it, naively thinking that would be all I need to do. But soon enough realised that sticking with any one single package manager is impractical, unless you're prepared to effectively narrow your choice of libraries to a subset of what's available. It seems like such an obvious problem, that I find it strange that the domain is still so fragmented. At the very least, you'd wonder why potential rivals wouldn't aim to make their products CMake compatible to start, and then work from there.
rwmj 5y ago
CMake is pretty good. However I have seen meson displacing autotools on several high profile projects, which is easy because autotools is horrible and full of footguns[1], and even those like me who use autotools all the time really don't like it very much. [1] Edit: An example of an autoconf footgun: We recently discovered that --disable-<FEATURE> for several features in nbdkit didn't work because we didn't use the AC_ARG_ENABLE macro correctly. When you used --disable-foo it actually enabled foo. How is it possible to design something like AC_ARG_ENABLE which is so easy to use incorrectly! https://gitlab.com/nbdkit/nbdkit/-/commit/be1fe9abb8e3a3448bd1deedf45f712736e7d8a5 https://gitlab.com/nbdkit/nbdkit/-/commit/be1fe9abb8e3a3448b...
Teknoman117 5y ago
Extremely wide support for one. CMake is the only build system with first class support for all of the major platforms - and those platforms' default tooling. I can't tell you how much Visual Studio adding CMake support reduced the barrier to support cross platform C++ projects. I'm a Linux user myself, but I interact with a lot of Windows developers and telling them to leave Visual Studio and use command line tools usually just means they won't be happy about working on a project.

I think a combination of - CMake has been around a _long_ time now, anything is slow to adopt in the C++ system, and people (rightly or wrongly) expect their build systems to be somewhat arcane - whilst CMake is in many cases magnitudes simpler and more portable than plain Makefiles/autoconf. In short, I think it's hard-won, and hard to let go of. Edit to add: Also, the "generates project files in multiple flavors/IDE format" makes it a very easy to sell as a path of migration, rather than a complete change.

bch 5y ago
Are you talking about cmake-generators(7)?
- misnome 5y ago
  Yes. Although I don't use them much myself (outside of Make/Ninja), I still think it is a big "Plus" when evaluating build systems next to each other.

danachow 5y ago

CMake has gotten better over the years. First line support in CLion is a thing.

pjmlp 5y ago
QtCreator and Visual Studio as well.

BBC-vs-neolibs 5y ago

What should we replace MSBuild with? CMake is on the table. We have a lot of MSbuild files, including and calling each other.

siwatanejo 5y ago
Why replace MSBuild?

jcelerier 5y ago

One of my main use cases for CMake is that it works very well as a Windows, Mac, Linux cross-platform busybox. It allows to download files from the internet, unzip / untar, compute SHA hashes, do file system operations, ... in a very shell-like way (https://cmake.org/cmake/help/v3.21/manual/cmake.1.html#run-a-command-line-tool https://cmake.org/cmake/help/v3.21/manual/cmake.1.html#run-a...). It's also been very useful in allowing to implement simple code parsing and generation thanks to its regex support, without having to install Perl (a pain on Win32), Bash (a pain on Win32), Python (same) and without requiring to build another binary doing the code parsing / code generation step (which generally causes a ton of problems as soon as you want to cross-compile since the code generation binary should be built with the host toolset - e.g. what if I want to run a code generator for a WASM target or some kind of VM as part of my build and don't want to have to run multiple build passes ?). Finally I like that I don't have to put all my strings in "" unlike other build systems, I find it much more readable. The Qt GUI has also been a very appreciated features of some of my users who: - want to build of my software on their machine - are technical enough to follow instructions on a GUI - are not technical enough to use a terminal which, from my experience, is a surprisingly large amount of people.

kcb 5y ago

Because worse that any current build system is having to learn and migrate to a new one.

stormbrew 5y ago

Honestly? Because cmake is actually really good. In spite of being very hampered by a bad bespoke programming language tacked on to its model, it does most of the things a meta-build system needs to do and it does them well, and it does them without needing java or python or basically a TSR server component running in the background to make it fast.

RScholar 5y ago
I think a lot of that can be chalked up to the fact that the minds behind CMake are pretty consistently top-notch--most of the Kitware folks have at least one post-grad CS degree and have not insignificant levels of experience approaching design problems from a more abstract/academic POV than your average dev team. I think over the years it's kept them from making the truly awful implementation blunders that send projects scrambling for another alternative just to 'never have to do THAT again.' Hence, CMake has had the time to seep into the way projects organize themselves in ways the "flavor of the month" build systems (qmake, scons, et al.) couldn't. What I'd like to know is where this supposedly excellent documentation for Meson is that the author refers to. The times that I've needed to use Meson have been uniformly unpleasant precisely because I found the official docs to have a ton of holes and also assumed an unrealistic level of familiarity with their underlying logic. Give me the CMake docs anyday; at least I can be relatively sure the answer's in there instead of hiding in a GitHub issue regarding some design flaw that'll be solved in the next release.
dynamite-ready 5y ago
I'm somewhat new to using C++ often enough to care about this. At times, it genuinely feels harder to link a project, than write the code. Having come from a webdev background, where well publicised package managers have effectively directed how a project should be built, C++'s ecosystem looks to have created the opposite situation, where the utility of a project or library appears to dictate which build manager is used, in most cases. Either you go with the grain and adopt your chosen library/environment's build system, or you increase the work you have to do. I liked GYP a lot, and when starting out, was trying to stick with it, naively thinking that would be all I need to do. But soon enough realised that sticking with any one single package manager is impractical, unless you're prepared to effectively narrow your choice of libraries to a subset of what's available. It seems like such an obvious problem, that I find it strange that the domain is still so fragmented. At the very least, you'd wonder why potential rivals wouldn't aim to make their products CMake compatible to start, and then work from there.

rwmj 5y ago

CMake is pretty good. However I have seen meson displacing autotools on several high profile projects, which is easy because autotools is horrible and full of footguns[1], and even those like me who use autotools all the time really don't like it very much. [1] Edit: An example of an autoconf footgun: We recently discovered that --disable-<FEATURE> for several features in nbdkit didn't work because we didn't use the AC_ARG_ENABLE macro correctly. When you used --disable-foo it actually enabled foo. How is it possible to design something like AC_ARG_ENABLE which is so easy to use incorrectly! https://gitlab.com/nbdkit/nbdkit/-/commit/be1fe9abb8e3a3448bd1deedf45f712736e7d8a5 https://gitlab.com/nbdkit/nbdkit/-/commit/be1fe9abb8e3a3448b...

Teknoman117 5y ago

Extremely wide support for one. CMake is the only build system with first class support for all of the major platforms - and those platforms' default tooling. I can't tell you how much Visual Studio adding CMake support reduced the barrier to support cross platform C++ projects. I'm a Linux user myself, but I interact with a lot of Windows developers and telling them to leave Visual Studio and use command line tools usually just means they won't be happy about working on a project.