- Ease of use: easy to use, discovering available options is easy. The
scripting language is straight-forward to use.
- IDE support: Supports generating build instructions for Xcode and Microsoft
Visual Studio, a plugin exists for Visual Studio Code.
- Out-of-tree builds: supported.
- Cross-platform builds: supported.
- Language support:
- C: Supported for GCC, Clang, MSVC and other toolchains.
- Rust: Supported for rustc.
- Test integration: supported. Interactive tests are supported starting with
Meson 1.5.0 via the `--interactive` flag.
I don't think that when reading these any of them stick out to me and
compel me to learn a new build system. I understand and am sympathetic
to the fact that GNU Make has odd syntax and can be cumbersome. But I
don't think that incrementally modifying our Makefile over time is
difficult, and it has certainly worked well over the years.
Certainly there is ample support for IDE integration with Make.
Out-of-tree builds and cross-platform builds could be supported in
theory as you note within the existing build system. Another suggestion
you make is that Meson has better native support for Rust, which I agree
may be important to consider in the future.
But I don't think that any of those three (out-of-tree builds,
cross-compilation, or Rust support) are insurmountable challenges in
Make. Certainly there is a lot of inertia there, but I don't think
that's a bad thing. Contributors are used to the existing build system,
it has worked well for us, works across many platforms and has (IMO)
stood the test of time.
I admittedly have a hard time squaring the benefits and goals we have
with Meson with the cost of learning a new build system, and/or moving
away from Make entirely.
I am entirely open to the possibility that there is something that I am
missing here, and that Meson really is a better choice for Git given our
current direction. But I think if that's true, then the series needs to
explain that more prominently.
== What is the eventual plan for CMake?
