This article relies too much on references to primary sources. (July 2017) (Learn how and when to remove this template message)
|Initial release||March 2, 2013|
0.49.0 / December 9, 2018
|Type||Software development tools|
|License||Apache 2.0 License|
Meson is like CMake in that it does not build software directly, but rather sets up a backend build system such as ninja on Linux, MSBuild on Windows or Xcode on macOS. The user then invokes the backend buildsystem. Because only out-of-tree builds are supported, it requires the user to create a build directory for this backend buildsystem and its outputs. The basic usage difference is that CMake defaults to make as a backend instead of ninja, but cmake -G Ninja behaves like Meson in this regard.
The syntax of Meson's build description files (the Meson language) borrows from Python, but is not Python: It is designed to be reimplementable in any other language – the dependency on Python is an implementation detail.
The Meson language is intentionally not Turing complete, and can therefore not express an arbitrary program. Instead, arbitrary build steps beyond compiling supported languages can be represented as custom targets.
The Meson language is strongly typed, such that builtin types like library, executable, string, and lists thereof, are non-interchangeable. In particular, unlike Make, the list type does not split strings on whitespace. Thus, whitespace and other characters in filenames and program arguments are handled cleanly.
|List datatype||Yes||semicolon delimited string||whitespace delimited string|
|Extensible via custom functions||No||Yes||Yes|
|Can read output of arbitrary commands (at configure time)||run_command||Yes||Yes|
|Can run arbitrary commands at build time as recipes of custom targets||Yes||Yes||Yes|
Speed and correctness
As with any typical buildsystem, correct incremental builds is the most significant speed feature (because all incremental progress is discarded whenever the user is forced to do a clean build).
Unlike bare Make, the separate configure step ensures that changes to arguments, environment variables and command output are not partially applied in subsequent builds, which would lead to a stale build.
Like Ninja, Meson does not support globbing of source files. By requiring all source files to be listed in the build definition files, the build definition file timestamps are sufficient to determine if the set of source files has changed, thereby ensuring that removed source files are detected. CMake supports globbing, but recommends against it for the same reason.
Meson uses ccache automatically if installed. It also detects changes to symbol tables of shared libraries to skip relinking executables against the library when there are no ABI changes. Precompiled headers are supported, but requires configuration. Debug builds are without optimization by default.
|Prohibits stale builds (partial rebuild against input change)||Yes (unless there are bugs)||If not globbing source files||Recursive Make (an idiomatic pattern) is broken in this respect|
|Ccache||Automatic||Trivial to add||Trivial to add|
|Distcc||?||Trivial to add||Trivial to add|
|Symbol table aware relinking||Yes||Do it yourself||Do it yourself|
|Precompiled headers||Optional||Broken solutions exist||Do it yourself|
A stated goal of Meson is to facilitate modern development practices. As such, Meson knows how to do unity builds, build with test coverage, link time optimization etc without the programmer having to write support for this.
|Set correct library installation directory on x86_64 Unix||Automatic||Not standardized|
Like CMake,CMake package Meson primarily uses pkg-config to find dependencies that are external to the project. This is not a solution to dependency hell, as the job of satisfying missing dependencies is on the user. Alternatively, the dependency can be internalized as a subproject – a Meson project within another – either contained or as a link. This has the drawback of contributing to software bloat in the case of common dependencies. The compromise favored by Linux packagers is to use the subproject as a fallback for the external dependency.
A problem is that Meson only supports Meson subprojects. For common dependencies, this is solved by patching in a Meson build file from the WrapDB service.
- Comparison of dependency resolution use cases in different build systems
|Finding installed dependencies||pkg-config||CMake module, pkg-config||?|
|Downloading dependencies automatically||subproject||No||Cargo dependency|
|Finding installed dependencies, with download fallback||pkg-config + subproject||No||?|
|pkg-config file generator||Yes||No||No|
|Facilitate use as an auto-downloadable dependency||Can be used as a Meson subproject||No||With registration to crates.io|
- ^CMake package CMake can use either CMake packages or pkg-config, but as the table shows, both are for finding installed dependencies.
Cross compilation requires extra configuration, which Meson supports in the form of a separate cross file, which can be external to the Meson project.
GNOME has made it a goal to port its projects to Meson. As of late 2017, GNOME Shell itself exclusively requires Meson after abandoning Autotools, and central components like GTK+, Clutter-GTK, GLib and GStreamer can be built with Meson.
The Meson homepage lists further projects using Meson.
- "Releases - mesonbuild/meson". Retrieved 9 December 2018 – via GitHub.
- "Making build systems not suck (linux.conf.au video)".
- "High productivity build system".
Meson aims to optimize programmer productivity by providing simple, out-of-the-box support for modern software development tools and practices, such as unit tests, coverage reports, Valgrind, CCache and the like.
- "mesonbuild/meson: The Meson Build System". GitHub. Retrieved 13 April 2016.
- "Reference manual".
- "Meson Frequently Asked Questions".
- "Meson Syntax".
- "CMake FILE command".
Note: We do not recommend using GLOB to collect a list of source files from your source tree. If no CMakeLists.txt file changes when a source is added or removed, the generated build system cannot know when to ask CMake to regenerate.
- "Non-recursive Make Considered Harmful" (PDF).
Recursive Make is considered harmful for very good reasons (Miller 1998); it is not possible to accurately track dependencies when the build system is constructed of separate components that invoke each other.
- "CMake support for precompiled headers". Retrieved 13 March 2018.
- "Wrap dependency system manual".
- "Meson and 3rd party dependencies. Only one correct way".
- "Cross compilation".
- "GNOME Goal: Port modules to use Meson build system".
- "GNOME 3.26 Beta Debuts: More Meson Porting, Wayland Action".
- "Drop support for autotools".
- "The Meson Build System Is Being Fitted For The X.Org Server".
- "Meson-ized Mesa Now Supports More Drivers".
- "List of projects using Meson".