The Meson Build System
http://mesonbuild.com/
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
58 lines
2.8 KiB
58 lines
2.8 KiB
--- |
|
short-description: Overview of the Meson build system |
|
... |
|
|
|
# Overview |
|
|
|
Meson is a build system that is designed to be as user-friendly as |
|
possible without sacrificing performance. The main tool for this is a |
|
custom language that the user uses to describe the structure of his |
|
build. The main design goals of this language has been simplicity, |
|
clarity and conciseness. Much inspiration was drawn from the Python |
|
programming language, which is considered very readable, even to |
|
people who have not programmed in Python before. |
|
|
|
Another main idea has been to provide first class support for modern |
|
programming tools and best practices. These include features as varied |
|
as unit testing, code coverage reporting, precompiled headers and the |
|
like. All of these features should be immediately available to any |
|
project using Meson. The user should not need to hunt for third party |
|
macros or write shell scripts to get these features. They should just |
|
work out of the box. |
|
|
|
This power should not come at the expense of limited usability. Many |
|
software builds require unorthodox steps. A common example is that you |
|
first need to build a custom tool and then use that tool to generate |
|
more source code to build. This functionality needs to be supported |
|
and be as easy to use as other parts of the system. |
|
|
|
Terminology |
|
-- |
|
|
|
Meson follows the overall structure of other popular build systems, |
|
such as CMake and GNU Autotools. This means that the build is divided |
|
into two discrete steps: *configure step* and *build step*. The first |
|
step inspects the system, checks for dependencies and does all other |
|
steps necessary to configure the build. It then generates the actual |
|
build system. The second step is simply executing this generated build |
|
system. The end result is a bunch of *build targets*, which are |
|
usually executables and shared and static libraries. |
|
|
|
The directory that contains the source code is called the *source |
|
directory*. Correspondingly the directory where the output is written |
|
is called the *build directory*. In other build systems it is common |
|
to have these two be the same directory. This is called an *in-source |
|
build*. The case where the build directory is separate is called an |
|
*out-of-source build*. |
|
|
|
What sets Meson apart from most build systems is that it enforces a |
|
separate build directory. All files created by the build system are |
|
put in the build directory. It is actually impossible to do an |
|
in-source build. For people used to building inside their source tree, |
|
this may seem like a needless complication. However there are several |
|
benefits to doing only out-of-source builds. These will be explained |
|
in the next chapter. |
|
|
|
When the source code is built, a set of *unit tests* is usually |
|
run. They ensure that the program is working as it should. If it does, |
|
the build result can be *installed* after which it is ready for use.
|
|
|