| --- | |
| 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. |