Comparing Meson with other build systems
A common question is Why should I choose Meson over a different build system X? There is no one true answer to this as it depends on the use case. Almost all build systems have all the functionality needed to build medium-to-large projects so the decision is usually made on other points. Here we list some pros and cons of various build systems to help you do the decision yourself.
Excellent support for legacy Unix platforms, large selection of existing modules.
Needlessly slow, complicated, hard to use correctly, unreliable, painful to debug, incomprehensible for most people, poor support for non-Unix platforms (especially Windows).
Great support for multiple backends (Visual Studio, XCode, etc).
The scripting language is cumbersome to work with. Some simple things are more complicated than necessary.
Full power of Python available for defining your build.
Slow. Requires you to pass your configuration settings on every invocation. That is, if you do
scons OPT1 OPT2 and then just
scons, it will reconfigure everything without settings
OPT2. Every other build system remembers build options from the previous invocation.
Proven to scale to very large projects.
Implemented in Java. Poor Windows support. Heavily focused on Google's way of doing things (which may be a good or a bad thing). Contributing code requires signing a CLA.
The fastest build system [see measurements](Performance comparison), user friendly, designed to be as invisible to the developer as possible, native support for modern tools (precompiled headers, coverage, Valgrind etc). Not Turing complete so build definition files are easy to read and understand.
Relatively new so it does not have a large user base yet, and may thus contain some unknown bugs. Visual Studio and XCode backends not as high quality as Ninja one.
The results of the search are