CMake feels a lot like C++89: Lots of things you can do, but there are problems:

* No standardization or opinionated design, so you can't share your work easily.

* No sane defaults, so your build system is always fragile, difficult to maintain, and done wrong.

* No best practices, so people keep making the same mistakes over and over.

* Misguided attempt to remain compatible with the steaming pile of legacy they've accumulated over the years.

* Bad documentation, so there's no way to learn how to do things better.

* Steep learning curve with limited payoff, so most people don't bother.

Meson does some of these things better. It's still not pretty, but it's nicer to use than CMake.

1 and 3 are not true anymore, the new canonical CMake way is targets with attached dependencies, header file search paths, compiler flags and possibly other things. Bad documentation - well yeah, it's specifically missing first-party best practices and howto documentation and the third-party documentation as well as really old first-party documentation in the CMake wiki often recommends bad old practices.

You forgot to mention that the language is awful (but that usually doesn't get in the way IME).

Xmake will be better, you can try it.

Nobody who has used CMake would ask that so I assume you haven't!

The answer is that CMake is mad and full of gotchas. Think of it like the PHP of build systems. Here is a classic example:

https://cmake.org/cmake/help/latest/command/if.html#variable...

This is a reasonable programming language design choice.

CMake actual gotchas I dislike enough to avoid it as much as possible include defaulting to cached information, even after I make changes, and preferring "smart", opaque and even hard to track down scripts to explicit user input. It seems optimized for cleverness and conciseness, at the expense of reliability and required user effort.

This is actually a useful comment and points out something I didn't know (about how the CMake if statement resolves variables).

In my experience the primary reason people migrate is that it is significantly simpler for ordinary developers to maintain and configure builds in Meson. They both target ninja but the learning curve for CMake is definitely steeper.

Cmake has tooling and is supported by IDEs. Does Meson have anything comparable?

A better question is does it need to have tooling or IDE support to be worked with?

It's good to have tooling and IDEs for CMake because CMake is complicated and hand-editing the files is very tedious. But if Meson eliminates the tedium of CMake by providing you with different abstractions then you don't actually need the IDEs or tooling.

CMake can generate IDE workspace files, which makes it possible to use Visual Studio almost natively - the almost being, the ide is "read only" with respect to project settings and files - but on a stable project, that feels very close to native.

I have not used Meson, but other build environments (e.g. Make) don't interact as well with IDEs as CMake does (with the exception of premake, which is mostly dead.

This is not what IDE support means for the most part. The big question is does the IDE understand how the files are compiled well enough for its autocompletion and jump-to-definition features to work. A build system/IDE combo which does not support this is DOA to most users. Sadly, there is no standardisation of the interface between IDEs, build systems, and compilers (though the language server spec from Microsoft is making some headway in this regard), so each of these integrations needs to be rebuilt each time, making development of new build systems extra painful.

> A better question is does it need to have tooling or IDE support to be worked with?

No, that's the wrong question and one that's only purpose is to deflect attention from its shortcomings.

All build tools need tooling because if they are adequately integrated into development workflows they are transparent and easy to use. Cmake meets that requirement, and until other alternative build systems do then they will always be far more complicated.

In my mind CMake and Meson are tools for engineers to use in solving problems. If one tool needs some support tooling in order to be usable, then I'm intrinsically less interested in using it simply because there's some extra stuff I have to bolt on before it becomes useful. So I don't see why you think it's "the wrong question" here.

Another poster has explained the IDE support is about IDEs being able to parse CMake files, and I can say that back in the day before CMake IDEs would parse the C/C++ directly using a compiler to output an abstract syntax tree that they would use. So for example Eclipse has this notion of "Build configurations" which allows you to control how this parsing occurs and which files the parser considers valid and what symbols are predefined. Which is IDE support very much like you're looking for from CMake. I worked with it for several years at my last job to provide support for other engineers working with a Make-based build system.

cmake has the best integration of any third party build tool, but if you can lock yourself to one IDE the ability to click "new file" and have the file created, added to version control, and the build system all in one easy step is powerful.

> A better question is does it need to have tooling or IDE support to be worked with?

C++ really benefits from it. ctrl+click on a symbol is much more sane than (re)teaching Argument Dependent Lookup rules to all of the engineers in your organization.

CMake is only complicated if you need to make use of its complicated features, which many build systems simply omit. Meson looks nice though.

Oh, the number of hours of my life I spent debugging CMake files of third party libraries.

You are very fortunate if you import libraries that just work. This is also true for "modern" CMake.

Bad code is an unfortunate fact of life. How does that go away. This could be either easier debugging, some enforcement of clean code (how is that possible), the tool is limited so you can't do complex things, or just so far only good coders have been involved not the masses of bad coders. My default assumption is the last, but I'm willing to be proven wrong.

Good defaults can take you very far.