CMake has been growing for 20 years, and in the past couple years several very major projects switched to CMake. So why consider moving to the far less mature Meson? CMake < 3.0 was very much a macro system, with little concept of namespaces. Legacy CMake script had difficult to understand behavior and syntax with confusing variable scope. While CMake 3.x made considerable modernization, the bulky, still confusing and verbose CMake syntax can leave the developer wanting for something more.
A key professed goal of Meson is to make the build system scripting faster and easier to understand, while making the build process itself also faster.
2018 saw several new capabilities and cleaner syntax introduced into Meson.
Entering 2019, Meson has reached the point where we are including
meson.build into many of our projects alongside (and independent from)
The purpose of this is to support the rapidly growing Meson ecosystem, making it easy for our code to be including as an external package into Meson, and likewise for CMake.
We can also discover bugs and missing features in Meson relevant to modern Fortran users, helping catalyze Meson as an HPC option.
If you use Anaconda Python:
conda install meson
or in general:
pip install meson
We recommend the
conda install meson method as this will also install a compatible Ninja version.
Like CMake, Meson is an out-of-source build, so a typical new build will start something like:
cd myproj/bin meson ../src # wherever meson.build is ninja
By default, Ninja builds in parallel.
Convert CMakeLists.txt to meson.build
makes a first pass at converting
The developer will need to manually complete this conversion process, but this script helps eliminate some of the tedious parts.