Why has it been so hard to displace CMake?
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.
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.
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.
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.
And at that point, your user's probably just gonna be asking "well I guess I may as well just use cmake."
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.
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.
[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/be1fe9abb8e3a3448b...