Looks like SciPy is now migrating to the meson build system to handle the compilation of their Fortran, C, C++ and Cython code:
The experience described in the article above matches pretty much mine when comparing meson with CMake for my mixed Fortran / Python projects and it has been mostly pleasant so far. While meson is already working quite nicely in this field, the interest of SciPy in meson might result in a further improved build system for both, the Python and the Fortran community.
Yes. I think Meson is an improvement over distutils, especially for these mixed Fortran, C++ and Python projects.
On a general level, the issue that I can see with Meson is that its configure file is in Python. That invites people to write scripts in Python to workaround (or just not knowing) the canonical way of doing things. Scons had the same issue. CMake didn’t use Python, but people still use its scripting language to hack around cmake limitations. That is unfortunate, because then every project’s build system becomes this unique “program” that is hard to follow and debug.
The only way that I know of to fix this general issue is to not allow any kind of scripting, but strictly use declarative syntax, such as fpm.toml or Cargo.toml. This could be done in Python in Meson, but Meson would have to check and allow only a small subset of Python. I don’t know if it does.
It is hard probably to do for a general build system like Meson, but doable for a language specific build system such as Cargo of fpm, as long as you are willing to restrict your project to what fpm or Cargo support; in return for very easy and uniform build system across all packages, which is a huge win.
Actually, meson’s build files use a DSL which might be inspired by Python, but not turing complete, you can’t use any Python in your build file by construction. What you can do is add external scripts and integrate them with, e.g. the install hook or use them to configure a file, but you rarely need them.