[junon]

This probably doesn't help much, but I've researched just about every build system in existence that some very extensive google and github searches could bring up.

Naturally, xmake came up. While I've not used it, and it doesn't really compat with much, it's not the most horribly designed build system out there.

CMake is still the defacto, it allows the most flexibility when needed (albeit very painfully) and provides good-enough support for hierarchical projects.

xmake doesn't solve any of the deficiencies CMake still has, and isn't close to feature parity. Further, it's not improving the 80% use case much over Cmake, which is simple enough for smaller libraries and packages and covers cases like packaging building and installation out of the box without really much extra overhead.

Unless a build system comes along that is 10x better at all aspects, I don't see CMake going anywhere.

Now if Autotools could just die already...

[thechao]

I feel like everything you just said is true if you replace “cmake” with “make” and “xmake” with “cmake”.

[Ericson2314]

Supporting gcc/clang and msvc with raw make is a pain. That's basically the number 1 CMake value add.

[rualca]

I would add that cmake is a makefile generator.

cmake's value is in the way it provides a high-level abstraction over all supported platflom's capabilities, and that it works by generating and running build scripts from lower level systems such as standard make.

For example, Cmake allows us to set the version of c++ a project uses with a single build target property, which is then used to pick which compiler's flags it uses with a given compiler. It then generates the makefile with all the relevant flags set, and runs that with ease.

This works regardless of platform or compiler.

[Ericson2314]

I agree separating the domain knowledge (CMake, Meson, etc.) from the build plan executor (ninja) is extremely good too, but one must be fair this isn't itself end-benefit to users.

If good architecture was an immediate end-user benefit, we'd get a lot less bad architecture from short-sighted institutions writing code!

[waruqi]

cmake is just a project generator, it does not have its own build system and package management.

and xmake = make + project generator + package manager

In addition, I don't like cmake's DSL syntax, which is very tedious and difficult to maintain.

[rualca]

>>In addition, I don't like cmake's DSL syntax, which is very tedious and difficult to maintain.

I don't agree that Cmake is difficult and hard to maintain.

I do believe that most people write complete messes in their makefile so that they become brittle and hard to maintain.

The so called "modern Cmake" approach, with its declarative approach to project files, is delightful to work with, unlike the old and beaten imperative based path of forcing Cmake to be a glorified scripting language when it never was.

[junon]

This. Many PRs that introduce CMake tend to be massive rats nests of configuration slurry that could be summed up in a tenth of the LOC.