Even if Meson is more "powerful", there are other build systems out there that are better options than either of these.
Meson is much more than just a different DSL. What is the CMake standard option for toggling between library types? What is the CMake standard option for toggling lto? What is the CMake standard option for enabling sanitizers?
Meson standardizes so much behavior. I can go to any project and immediately be able to configure a build with the parameters that I want.
-DBUILD_SHARED_LIBS=<ON,OFF>
> What is the CMake standard option for toggling lto?
-DCMAKE_INTERPROCEDURAL_OPTIMIZATION=<ON,OFF>
> What is the CMake standard option for enabling sanitizers?
There isn't one, sadly. Though, you can set CXXFLAGS to configure whatever behaviour you want.
To clarify, I mean "better" for complex tasks. Build systems are just tools like any other, meaning they're good at some things, but bad at others. CMake (and Meson) are good for simpler build scenarios, but when you need complexity they're a poor choice. For that you're better off with scons, waf, bazel, ant, buck, gradle, etc.
> Meson is much more than just a different DSL. What is the CMake standard option for toggling between library types? What is the CMake standard option for toggling lto? What is the CMake standard option for enabling sanitizers?
> Meson standardizes so much behavior. I can go to any project and immediately be able to configure a build with the parameters that I want.
Again, my issue with Meson is that it doesn't bring anything substantially new to the table to justify it. Having a nicer DSL isn't enough, and having some built in toggles for common things isn't enough. The fact that you happen to be more comfortable with Meson doesn't make it objectively better than CMake. Figuring out how to enable LTO and sanitizers for a CMake project might take a few minutes of Googling at most.
A new dev who has never encountered either of these might instinctively prefer Meson's syntax, but the wiser decision is to learn the (vastly) more mature and prolific CMake, and then not have to worry about it. Time spent on the build system is time not spent on the project.
... and loads of extra dogma about how projects should be structured that don't match reality, paired with a rude and dismissive BDFL maintainer.
I like Meson's python-like language much better, though.
Ultimately, it doesn't make sense to worry too much about picking one or the other though.
I spent a ton of time adjusting toolchains and doing string handling, regex handling or command invocations with escapes, lists vs strings etc. in CMake.
Dnt get me started with options vs set in CMake and caching...
The waste of time was so massive and frustrating that I ended up moving to Meson.
It is working remarkably better.
Meson was easier to pick up. Not nearly as easy as I feel it should be (the idea of a meta build system when you target a single platform has always struck me as insane), but still easier than CMake.
who targets a single platform in 2022 ? I have honestly never in my professional life worked on non-embedded C++ projects that only targeted one platform (and honestly, even those had to run on host computers with people developing from any host OS, Mac / Win / Linux) ; on the other hand I had a lot of time people ask me to have support for working on the project from either Xcode, Visual Studio or others IDE. How do you do that without a meta-build system?
Me, in the last 3 jobs I worked on. In fact, the majority of my career targets a single platform. I believe it's common for applications to target only one platform. Even when Windows is the first such platform. Heck, I've even read some advice about re-writing your application instead of trying to make it multi-platform.
Libraries are different, though. And that application you plan to rewrite 3-6 times should probably offload the entire business logic to a truly multi-platform library. So I guess meta-build systems could possibly make some sense there.
Still, what I've seen in practice is an extremely shallow layer of non-abstraction that just hides what actual commands happen under the hood. I know how to call a compiler on the command line, I know its inputs and output, and I can reuse this knowledge when I write a Makefile. CMake, not so much.
> on the other hand I had a lot of time people ask me to have support for working on the project from either Xcode, Visual Studio or others IDE. How do you do that without a meta-build system?
My feeling is that it's not the job of the (meta) build system to support the idiosyncrasies of the latest IDE (or editor) of the day. It's the job of the IDE to provide what users need to call the right build command for the right situation (build debug, build release, clean…). And for fancy stuff like auto-completion and jump to definition, the IDE should provide the necessary magic independently of the actual build system used.
If this independence between the build system and the IDE cannot be achieved, then maybe the language is the problem. I know, people are doing real work and have no time for long term plans. Just, the absence of a short term solution doesn't mean there is no problem.
Early in my career, I worked on a project that built for 4 platforms, not all x64, and was managed through msbuild, i.e. it just worked in visual studio.
* Visual Studio Projects * Ninja * XCode
That was in 2014. If that was their most recent screw-up, they're doing pretty good.
> That's strike 2 after never integrating with pkgconfig and instead having you write shitty FindFoo files for everything.
There is pkgconfig integration [1], though most libraries autogenerate CMake config files these days.
[1]: https://cmake.org/cmake/help/latest/module/FindPkgConfig.htm...
Yes, of course there is some magic macro, but I already declared the dependency, please just find it, I'm not here to put boilerplate into Find scripts.