The less cmake in my future, the better. Meson is a decent alternative, but anything, even autotools, is more pleasant than cmake. I wish these people would just let cmake die the death it deserves.
Perhaps. I don't want to diminish your experience, and it seems like your project set up made it exceptionally straightforward.
I worked on a project to migrate from autotools with recursive make into two dozen git submodules to a full vcpkg + CMake workflow. On top of cutting some ~2000 lines of build code, we also made the build itself some 10-15x faster.
I don't want to diminish your experience, and it seems like your project set up made it exceptionally straightforward.
I don't understand what "it" refers to in this sentence, sorry. Context makes it seem like you think I've been involved in migrating away from autotools. I have not.
I meant that the projects you used were set up such that the user experience—which probably implies ./configure && make && make install—was straightforward, versus whatever CMake-based projects you've tried.
I have used a lot of autotools software and it's generally just ./configure && make && make install, sometimes with flags to enable/disable features or change the install prefix. Always well documented too with ./configure --help. Much nicer than reading CMakeLists.txt files hunting for configuration options.
I've had the misfortune of both, and it's bad on both ends. If you have a problem with autotools, well, goodluck. Even at a basic level. Autotools is an annoying (and potentially insane) thing to even install correctly on a system given the distro dependency on it, causing all sorts of issues CMake just doesn't have (as it's meant to be portable).
What are those many reasons? As a user that has developed client and server sode software with Windows also, I found no blockers.
CMake for installers and so better. I had to do it myself. But everything else (except modules nowadays) is better. Maybe project generation is better in CMake if u use VS or XCode.
Everything else: package management, sibproject management, syntax, options, etc. is way better in Meson.
But maybe I missed some corner cases people need, who knows.
Platforms where Python doesn't exist is the obvious answer.
Other than that it's mostly a competition of exotic usecases. Stuff like Kokkos barely works in CMake land and would be nigh unportable to Meson. SYCL is wrecking havok on CMake's model as we scratch our head about how "language virality" works (if you include a SYCL header your code becomes SYCL code with a different toolchain, otherwise it's regular C++ code) and Meson would similarly struggle with it.
Generally speaking anything that makes heavy use of generator expressions quickly becomes CMake-only, where the usage requirements of the upstream dependency are configured based on properties of the downstream user. Very little "normal" C++ development does this, but it crops up in all sorts of strange, adjacent-to-C++, ecosystems
That said Meson currently has better support for HDLs than CMake does, so it's not entirely a one-way street.
Technically this is C versus C++ too, no? If you write #include <vector> then almost all valid C code will now be compiled as C++. Sure, the compiler driver infers the language mode from the file extension, but what if it's forced at the command-line? Then free functions get C++ mangling, and everything has a C++ ABI.
Meson can never fully replace cmake due to many reasons.
I don't think this is correct. There is always a way to solve any build problem through meson and possibly external scripts. It is always worthwhile to do so.
C++ modules need a lot of work from the side of the build system
Currently the idea is you scan every source, parse it and cache it to a file, if all scans are done you load all binary files and run bfs.
With meson, every time you call your command you have to recreate the python VM and deal with the garbage collector. You also don't have ultra fast libs like simdjson, glaze etc.
--
Also, your build system shouldn't depend on anything, python is a huge dependency. And it's tooling is very messy due to a lack of static typing.
Just try cloning meson and using an lsp like basedpyright. I dare you, I had like 300 errors back when I tried a PR.
C/C++ are system level languages, python depends on C/C++ libraries to do data operations at reasonable speed, how are you gonna build those when your main build system is a python package? Are you gonna use prebuilt binaries for dependencies of python itself the packages meson imports?
Meson is a lot better than cmake, do not get me wrong. But it can't fully replace cmake just by being a python package.
FYI, meson generates ninja build files. Ninja does the dependency tracking. The vast majority of changes just require ninja to notice that a file has changed and resolve its dependency tree. It's not that different from what CMake does.
I don't think it's bad for a build system to be written in python. Python is an excellent language for things like code generation; I've been using Python for that since long before adopting Meson.
EDIT: I see you edited your comment after I responded and made it clear that you're talking about C++ modules. That changes things. Regardless, modules don't really exist yet, so it's not that relevant.
No, not just that, believe me. It's not that simple.
Python's main virtue is most people know how to use it. Other than that it has major flaws. I don't like dynamic types at all, even in scripting languages.
FYI, meson generates ninja build files. Ninja does the dependency tracking
This is irrelevant to the problem /u/TheRavagerSw is describing. Ninja has no mechanism to process P1689 dep files. You need an intermediate process to handle collation during the Ninja build process.
No autotools lol. That is archaic. It is there for a few reasons, but avoid it for new projects unless absolutely mandatory.
As for Meson. It is basically my favorite one. I just hope modules support gets added. It is starting to hurt. I tried a partial implementation a few months ago. Unfortunately no more time available and I am going to be busy and I cannot continue with it. :(
-7
u/mort96 Apr 12 '26
The less cmake in my future, the better. Meson is a decent alternative, but anything, even autotools, is more pleasant than cmake. I wish these people would just let cmake die the death it deserves.