Cross and Native File reference
Cross and native files are nearly identical, but not completely. This is the documentation on the common values used by both, for the specific values of one or the other see the cross compilation and native environments.
Changed in 0.56.0 Keys within sections are now case sensitive. This is *required to make project options work correctly.
There are four basic data types in a machine file:
A string is specified single quoted:
[section] option1 = 'false' option2 = '2'
An array is enclosed in square brackets, and must consist of strings or booleans
[section] option = ['value']
A boolean must be either
false, and unquoted.
option = false
An integer must be either an unquoted numeric constant;
option = 42
The following sections are allowed:
- project options
- built-in options
String and list concatenation is supported using the
+ operator, joining paths
is supported using the
Entries defined in the
[constants] section can be used in any other section
(they are always parsed first), entries in any other section can be used only
within that same section and only after it has been defined.
[constants] toolchain = '/toolchain' common_flags = ['--sysroot=' + toolchain / 'sysroot'] [properties] c_args = common_flags + ['-DSOMETHING'] cpp_args = c_args + ['-DSOMETHING_ELSE'] [binaries] c = toolchain / 'gcc'
This can be useful with cross file composition as well. A generic cross file could be composed with a platform specific file where constants are defined:
# aarch64.ini [constants] arch = 'aarch64-linux-gnu'
# cross.ini [binaries] c = arch + '-gcc' cpp = arch + '-g++' strip = arch + '-strip' pkgconfig = arch + '-pkg-config' ...
This can be used as
meson setup --cross-file aarch64.ini --cross-file cross.ini builddir.
Note that file composition happens before the parsing of values. The example
below results in
# file1.ini: [constants] a = 'Foo' b = a + 'World'
#file2.ini: [constants] a = 'Hello'
The example below results in an error when file1.ini is included before file2.ini
b would be defined before
# file1.ini: [constants] b = a + 'World'
#file2.ini: [constants] a = 'Hello'
The binaries section contains a list of binaries. These can be used
internally by meson, or by the
These values must be either strings or an array of strings
Compilers and linkers are defined here using
<lang>_ld is special because it is compiler specific. For compilers like
gcc and clang which are used to invoke the linker this is a value to pass to
their "choose the linker" argument (-fuse-ld= in this case). For compilers
like MSVC and Clang-Cl, this is the path to a linker for meson to invoke,
lld-link.exe. Support for
ld is new in 0.53.0
changed in 0.53.1 the
ld variable was replaced by
<lang>_ld, because it
*regressed a large number of projects. in 0.53.0 the
ld variable was used
c = '/usr/bin/clang' c_ld = 'lld' sed = 'C:\\program files\\gnu\\sed.exe' llvm-config = '/usr/lib/llvm8/bin/llvm-config'
c = ['ccache', '/usr/bin/i586-mingw32msvc-gcc'] cpp = ['ccache', '/usr/bin/i586-mingw32msvc-g++'] c_ld = 'gold' cpp_ld = 'gold' ar = '/usr/i586-mingw32msvc/bin/ar' strip = '/usr/i586-mingw32msvc/bin/strip' pkgconfig = '/usr/bin/i586-mingw32msvc-pkg-config'
An incomplete list of internally used programs that can be overridden here is:
- wx-config (or wx-3.0-config or wx-config-gtk)
Paths and Directories
Deprecated in 0.56.0 use the built-in section instead.
As of 0.50.0 paths and directories such as libdir can be defined in the native and cross files in a paths section. These should be strings.
[paths] libdir = 'mylibdir' prefix = '/my prefix'
These values will only be loaded when not cross compiling. Any arguments on the
command line will override any options in the native file. For example, passing
--libdir=otherlibdir would result in a prefix of
/my prefix and a libdir of
New in native files in 0.54.0, always in cross files.
In addition to special data that may be specified in cross files, this
section may contain random key value pairs accessed using the
Changed in 0.56.0 putting
<lang>_link_args in the
properties section has been deprecated, and should be put in the built-in
This is a non exhaustive list of supported variables in the
cmake_toolchain_filespecifies an absolute path to an already existing CMake toolchain file that will be loaded with
include()as the last instruction of the automatically generated CMake toolchain file from meson. (new in 0.56.0)
cmake_defaultsis a boolean that specifies whether meson should automatically generate default toolchain variables from other sections (
host_machine, etc.) in the machine file. Defaults are always overwritten by variables set in the
[cmake]section. The default is
true. (new in 0.56.0)
cmake_skip_compiler_testis an enum that specifies when meson should automatically generate toolchain variables to skip the CMake compiler sanity checks. This only has an effect if
true. Supported values are
dep_only. The default is
dep_only. (new in 0.56.0)
cmake_use_exe_wrapperis a boolean that controls whether to use the
[binaries]to run generated executables in CMake subprojects. This setting has no effect if the
exe_wrapperwas not specified. The default value is
true. (new in 0.56.0)
New in 0.56.0
All variables set in the
[cmake] section will be added to the generate CMake
toolchain file used for both CMake dependencies and CMake subprojects. The type
of each entry must be either a string or a list of strings.
Note: All occurrences of
\ in the value of all keys will be replaced with
/ since CMake has a lot of issues with correctly escaping
dealing with variables (even in cases where a path in
is correctly escaped, CMake will still trip up internaly for instance)
A custom toolchain file should be used (via the `cmake_toolchain_file` property) if `\` support is required.
[cmake] CMAKE_C_COMPILER = '/usr/bin/gcc' CMAKE_CXX_COMPILER = 'C:\\user\\bin\\g++' CMAKE_SOME_VARIABLE = ['some', 'value with spaces']
For instance, the
[cmake] section from above will generate the following
code in the CMake toolchain file:
set(CMAKE_C_COMPILER "/usr/bin/gcc") set(CMAKE_C_COMPILER "C:/usr/bin/g++") set(CMAKE_SOME_VARIABLE "some" "value with spaces")
Project specific options
New in 0.56.0
Path options are not allowed, those must be set in the
Being able to set project specific options in a cross or native file can be
done using the
[project options] section of the specific file (if doing a
cross build the options from the native file will be ignored)
For setting options in subprojects use the
[project options] build-tests = true [zlib:project options] build-tests = false
Meson built-in options
Meson built-in options can be set the same way:
[built-in options] c_std = 'c99'
You can set some meson built-in options on a per-subproject basis, such as
werror. The order of precedence is:
- Command line
- Machine file
- Build system definitions
[zlib:built-in options] default_library = 'static' werror = false
Options set on a per-subproject basis will inherit the option from the parent if the parent has a setting but the subproject doesn't, even when there is a default set meson language.
[built-in options] default_library = 'static'
will make subprojects use default_library as static.
Some options can be set on a per-machine basis (in other words, the value of the build machine can be different than the host machine in a cross compile). In these cases the values from both a cross file and a native file are used.
An incomplete list of options is:
Loading multiple machine files
Native files allow layering (cross files can be layered since meson 0.52.0). More than one file can be loaded, with values from a previous file being overridden by the next. The intention of this is not overriding, but to allow composing files. This composition is done by passing the command line argument multiple times:
meson setup builddir/ --cross-file first.ini --cross-file second.ini --cross-file thrid.ini
In this case
first.ini will be loaded, then
second.ini, with values from
first.ini, and so on.
For example, if there is a project using C and C++, python 3.4-3.7, and LLVM 5-7, and it needs to build with clang 5, 6, and 7, and gcc 5.x, 6.x, and 7.x; expressing all of these configurations in monolithic configurations would result in 81 different native files. By layering them, it can be expressed by just 12 native files.
The results of the search are