The biggest problem is that, despite the many different solutions, no build system has come out as a clear winner for C/C++. So every library out there uses a different build system, and to use them all in your app, you must degenerate to makefiles in order to be able to call all the different build tools you need for each library.
Every now and then, a new god build system comes out (one builder to rule them all), which only exacerbates the problem.
Until the C++ language leaders bless a particular builder, this will continue.
Cmake has kind of won the popularity contest, but you see so many alternatives popping up, because Cmake is really difficult and slow.
Blessing one build system is only the answer if you've found something that works well for everybody.
Meson is the closest I've seen to maintainable build scripts, speed, and robust builds. But it doesn't have the popularity. Cmake has the popularity but isn't that great in any of the other dimensions.
I wish people would just settle on CMake. Since version 3, CMake + ninja handles everything in a reasonably cross-platform way.
Yes, debugging CMake is a pain. Yes, the syntax is unlike other languages. No, there isn't good modern documentation. Since it's been around so long people often learn old-style CMake (pre 3.0) from ancient webpages from lost corners on the internet. But right now, it's the standard that packages should settle on.
The CMake documentation is pretty good actually. I don't think people really want to settle on it though because the language is so awful. Almost as bad as Bash.
I've tried a lot of build systems but IMHO CMake is the only one where you can get away with just using CMake and the platforms target compiler. The rest includes additional pain points, more stuff to set up and configure.
What's missing from my point is the community getting together and defining a canonical way to actually build CMake projects for all use cases. If you look at github, there is hardly any project using CMake to the extent of its abilities, or things stuck in CMake 2 days. In commercial scenarios I've seen even worse.
Package manager make this even worse since all of them neglect the fact that there actually may be packages available on a platform via existing package managers. What puts me of about vcpkg or conan is that on a Linux box this should just allow one to use yum/apt/etc instead of manually downloading from yet another 3rd party. Having yet another repository is pretty much only usable for non-commercial projects where things such as long-term support barely have a meaning.
> this should just allow one to use yum/apt/etc instead of manually downloading from yet another 3rd party
That wouldn't work on its own. You also need something like pkg-config so you know how to build against the packages. You need to know about indirect dependencies and include search paths for instance.
> there is hardly any project using CMake to the extent of its abilities
I disagree. Every CMake project I've worked on does some weird thing that you couldn't do with Meson or XMake or whatever.
I'd be happy with CMake being the defacto C++ build system if its language wasn't so god awful. The most unforgivable things are that `if()` is broken and there's no real list type (they're just semicolon-delimited strings, with extra complications). In fact everything is a string.
Unfortunately this will never happen. The C++ committee, to my understanding, has made it very clear that they want to bless no tooling and are only concerned with the language itself.
Maybe it would be a better situation of a secondary organization started up that acted similarly to how NodeJS as a tooling platform operates with ECMAScript, the language definition.
I'm really quite fond of C++ the language, but the tooling around it always makes me hesitant to try anything new with it when so many other languages' ecosystems have come so far.
One very nice feature of CMake is that it can create project files for different IDEs. Add that to XMake if you want to be competitive with CMake as at least on Windows, it's a time saver to be able to use Visual Studio to build a C++ project as you can directly debug easily.
It's also one of the most problematic thing at the same time since getting the generators set up properly to output IDE usable stuff for a project that e.g. needs to be usable in IDEs on Windows, macOS and Linux is very time-consuming. Writing macros to make this work has been nerve wracking IMHO.
10 comments
[ 2.8 ms ] story [ 33.5 ms ] threadEvery now and then, a new god build system comes out (one builder to rule them all), which only exacerbates the problem.
Until the C++ language leaders bless a particular builder, this will continue.
Blessing one build system is only the answer if you've found something that works well for everybody.
Meson is the closest I've seen to maintainable build scripts, speed, and robust builds. But it doesn't have the popularity. Cmake has the popularity but isn't that great in any of the other dimensions.
Yes, debugging CMake is a pain. Yes, the syntax is unlike other languages. No, there isn't good modern documentation. Since it's been around so long people often learn old-style CMake (pre 3.0) from ancient webpages from lost corners on the internet. But right now, it's the standard that packages should settle on.
What's missing from my point is the community getting together and defining a canonical way to actually build CMake projects for all use cases. If you look at github, there is hardly any project using CMake to the extent of its abilities, or things stuck in CMake 2 days. In commercial scenarios I've seen even worse.
Package manager make this even worse since all of them neglect the fact that there actually may be packages available on a platform via existing package managers. What puts me of about vcpkg or conan is that on a Linux box this should just allow one to use yum/apt/etc instead of manually downloading from yet another 3rd party. Having yet another repository is pretty much only usable for non-commercial projects where things such as long-term support barely have a meaning.
That wouldn't work on its own. You also need something like pkg-config so you know how to build against the packages. You need to know about indirect dependencies and include search paths for instance.
I disagree. Every CMake project I've worked on does some weird thing that you couldn't do with Meson or XMake or whatever.
I'd be happy with CMake being the defacto C++ build system if its language wasn't so god awful. The most unforgivable things are that `if()` is broken and there's no real list type (they're just semicolon-delimited strings, with extra complications). In fact everything is a string.
Maybe it would be a better situation of a secondary organization started up that acted similarly to how NodeJS as a tooling platform operates with ECMAScript, the language definition.
I'm really quite fond of C++ the language, but the tooling around it always makes me hesitant to try anything new with it when so many other languages' ecosystems have come so far.