|
|
|
---
|
|
|
|
short-description: Style recommendations for Meson files
|
|
|
|
...
|
|
|
|
|
|
|
|
# Style recommendations
|
|
|
|
|
|
|
|
This page lists some recommendations on organizing and formatting your
|
|
|
|
Meson build files.
|
|
|
|
|
|
|
|
## Tabs or spaces?
|
|
|
|
|
|
|
|
Always spaces. Two spaces is the most common.
|
|
|
|
|
|
|
|
## Trailing commas?
|
|
|
|
|
|
|
|
Yes, where possible. They help make nicer diffs in version control systems.
|
|
|
|
|
|
|
|
## Naming Variable
|
|
|
|
|
|
|
|
Snake case (stylized as `snake_case`) refers to the style of writing in which
|
|
|
|
each space is replaced by an underscore (`_`) character, and the first letter of
|
|
|
|
each word written in lowercase. It is the most common naming convention used
|
|
|
|
in Meson build scripts as identifiers for variable.
|
|
|
|
|
|
|
|
Let say you would like to refer to your executable so something like `my_exe`.
|
|
|
|
|
|
|
|
## Dependency usage
|
|
|
|
|
|
|
|
The `dependency` function is the recommended way to handle
|
|
|
|
dependencies. If your wrap files have the necessary `[provide]`
|
|
|
|
entries, everything will work automatically both when compiling your
|
|
|
|
own and when using system dependencies.
|
|
|
|
|
|
|
|
You should only need `subproject` when you need to extract non dependencies/programs.
|
|
|
|
|
|
|
|
## Naming options
|
|
|
|
|
|
|
|
There are two ways of naming project options. As an example for
|
|
|
|
booleans the first one is `foo` and the second one is `enable-foo`.
|
|
|
|
The former style is recommended, because in Meson options have strong
|
|
|
|
type, rather than being just strings.
|
|
|
|
|
|
|
|
You should try to name options the same as is common in other
|
|
|
|
projects. This is especially important for yielding options, because
|
|
|
|
they require that both the parent and subproject options have the same
|
|
|
|
name.
|
|
|
|
|
|
|
|
# Global arguments
|
|
|
|
|
|
|
|
Prefer `add_project_arguments` to `add_global_arguments` because using
|
|
|
|
the latter prevents using the project as a subproject.
|
|
|
|
|
|
|
|
# Cross compilation arguments
|
|
|
|
|
|
|
|
Try to keep cross compilation arguments away from your build files as
|
|
|
|
much as possible. Keep them in the cross file instead. This adds
|
|
|
|
portability, since all changes needed to compile to a different
|
|
|
|
platform are isolated in one place.
|
|
|
|
|
|
|
|
# Sorting source paths
|
|
|
|
|
|
|
|
The source file arrays should all be sorted. This makes it easier to
|
|
|
|
spot errors and often reduces merge conflicts. Furthermore, the paths
|
|
|
|
should be sorted with a natural sorting algorithm, so that numbers are
|
|
|
|
sorted in an intuitive way (`1, 2, 3, 10, 20` instead of `1, 10, 2,
|
|
|
|
20, 3`).
|
|
|
|
|
|
|
|
Numbers should also be sorted before characters (`a111` before `ab0`).
|
|
|
|
Furthermore, strings should be sorted case insensitive.
|
|
|
|
|
|
|
|
Additionally, if a path contains a directory it should be sorted before
|
|
|
|
normal files. This rule also applies recursively for subdirectories.
|
|
|
|
|
|
|
|
The following example shows correct source list definition:
|
|
|
|
|
|
|
|
```meson
|
|
|
|
sources = files(
|
|
|
|
'aaa/a1.c',
|
|
|
|
'aaa/a2.c',
|
|
|
|
'bbb/subdir1/b1.c',
|
|
|
|
'bbb/subdir2/b2.c',
|
|
|
|
'bbb/subdir10/b3.c',
|
|
|
|
'bbb/subdir20/b4.c',
|
|
|
|
'bbb/b5.c',
|
|
|
|
'bbb/b6.c',
|
|
|
|
'f1.c',
|
|
|
|
'f2.c',
|
|
|
|
'f10.c',
|
|
|
|
'f20.c',
|
|
|
|
)
|
|
|
|
```
|