3 ms·

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

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.
- stormbrew 5y ago
  It would be very hard, mostly. At least without just embedding cmake to begin with. The language is so quirky and the quirks even vary by version (if you have a cmake project long enough you'll start to see warnings about quirks you're relying on from old versions that you can flag on or off). And at that point, your user's probably just gonna be asking "well I guess I may as well just use cmake."

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.

stormbrew 5y ago
It would be very hard, mostly. At least without just embedding cmake to begin with. The language is so quirky and the quirks even vary by version (if you have a cmake project long enough you'll start to see warnings about quirks you're relying on from old versions that you can flag on or off). And at that point, your user's probably just gonna be asking "well I guess I may as well just use cmake."