Meson (software)

src: i.ytimg.com

Meson (/'m?.s?n/) is a software tool for automating the building (compiling) of software. The overall goal for Meson is to promote programmer productivity.

Meson is free and open-source software written in Python 3 and subject to the terms of the Apache 2.0 License.

Video Meson (software)

Philosophy

The correct thing to do must also be the simplest thing to do.

--Jussi Pakkanen

Meson is opinionated. It not only strives to be easy to use right - being readable, having few surprises and having nice features that the developer gets for free by using the build system - but also hard to use wrong: Meson recognizes that build systems are almost universally hated by developers, and consequently, that the interest for learning to use them correctly is low. Therefore, Meson sees it as important to enforce established best practices. For example, its typed syntax discourages treating dependencies too naively.

Another high goal of Meson is fast and reliable incremental builds. This is to help programmers stay in the zone during repeated write-compile-debug cycles. The programmer must not have to think about which specific parts to rebuild, and silent stale builds are not acceptable.

Maps Meson (software)

Interoperability

Being written in Python, Meson runs natively on Unix-like operating systems, including macOS, as well as Microsoft Windows and on other operating systems.

Meson supports the C, C++, D, Fortran, Java, Rust and Vala languages, and has a mechanism for handling dependencies called Wrap.

Meson supports GNU Compiler Collection, Clang, Microsoft Visual Studio and others.

src: i.ytimg.com

Usage

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, like in CMake, 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.

src: pbs.twimg.com

Language

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.

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 have changed, thereby ensuring that removed source files are detected. CMake supports globbing, but recommends against it for the same reason.

src: i.ytimg.com

Features

To speed up incremental compilation, 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.

As a matter of correctness, changes to build definitions are detected and automatically triggers a rerun of Meson. The user is never supposed to have to rerun Meson manually. This differs from Make, which does not detect changes to build definitions or environment variables that affect the build (unless programmed to do so) - a common pitfall with Make is changing the compiler flags.

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.

Subprojects

Like CMake, Meson primarily uses pkg-config to find dependencies that are external to the project. However, this is not a solution to dependency hell - the task of finding 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; bundling of 3rd party dependencies is frowned upon by Linux distributions. As a compromize, the subproject can be used 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.

Cross compilation

Cross compilation requires extra configuration, which Meson supports in the form of a separate cross file, which can be external to the Meson project.

src: pbs.twimg.com

Adopters

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.

Systemd relies on Meson since dropping Autotools in version 234.

Efforts are made to port Xorg and Mesa to Meson.

The Meson homepage lists further projects using Meson.

src: i.ytimg.com

See also

• List of build automation software § Build script generation
• Autotools
• CMake
• Qmake

src: res.infoq.com

References

src: i.ytimg.com

External links

• Official website
• Meson Wiki: module reference at GitHub
• Meson Wiki: list of conference presentations at GitHub
• Nirbheek Chauhan at GUADEC2016: "Making your GNOME app compile 2.4x faster" on YouTube

Source of article : Wikipedia