Unfortunately even if you're starting a new project chances are that your dependencies are using cmake and they expect their dependencies to use cmake... in the end of the day you spend a lot of time fixing the upstream projects build files.

More than that CMake at this point is the ""standard"" and there are many others with a similar share of the market and selling points, it makes it harder to pick one that is not CMake.

Meson supports CMake subprojects: https://mesonbuild.com/CMake-module.html#cmake-subprojects

CMake subprojects was far from reliable last time I tested it. But this might also have been due to meson targeting unreleased CMake versions...

If your dependencies use CMake or not doesn't really matter, you still end up writing some FindX.cmake file.

(Which is a whole other thing with this "modern CMake" by the way: only half of them that come with CMake are "upgraded" to modern and if you don't want to require the absolute latest version, you end up having to check what the FindX script did or redefine stuff manually)

I will consider it when QtCreator, Visual Studio, Eclipse CDT, Clion give the same support as they offer currently for CMake based projects.

Why would I want to use Meson over CMake? Why would I regret using CMake?

I had a look at the Meson FAQ and it says:

> What is the correct way to use threads (such as pthreads)? > > thread_dep = dependency('threads') > > People coming from Autotools or CMake want to do this by looking for libpthread.so manually.

... which is false. We do:

> find_package(Threads REQUIRED) > target_link_library(my_app Threads::Threads)

and Bob's your uncle.

Doesn't meson bring in all of python3 as a dependency for a project? Similar to scons.

(It's been a while since I did semi-serious C++, maybe nowadays we're playing a bit more loose with deps and polyglot setups)

Does that matter? CPython comes preinstalled on basically every Linux distribution as a dependency for some other program these days.