short-description: Built-in options to configure project properties ...

Built-in options

Meson provides two kinds of options: build options provided by the build files and built-in options that are either universal options, base options, compiler options.

Universal options

A list of these options can be found by running meson --help. All these can be set by passing -Doption=value to meson (aka meson setup), or by setting them inside default_options of project() in your meson.build. Some options can also be set by --option=value, or --option value--- a list is shown by running meson setup --help.

For legacy reasons --warnlevel is the cli argument for the warning_level option.

They can also be edited after setup using meson configure -Doption=value.

Installation options are all relative to the prefix, except:

  • When the prefix is /usr: sysconfdir defaults to /etc, localstatedir defaults to /var, and sharedstatedir defaults to /var/lib
  • When the prefix is /usr/local: localstatedir defaults to /var/local, and sharedstatedir defaults to /var/local/lib

Directories

OptionDefault valueDescription
prefixsee belowInstallation prefix
bindirbinExecutable directory
datadirshareData file directory
includedirincludeHeader file directory
infodirshare/infoInfo page directory
libdirsee belowLibrary directory
libexecdirlibexecLibrary executable directory
localedirshare/localeLocale data directory
localstatedirvarLocalstate data directory
mandirshare/manManual page directory
sbindirsbinSystem executable directory
sharedstatedircomArchitecture-independent data directory
sysconfdiretcSysconf data directory

prefix defaults to C:/ on Windows, and /usr/local otherwise. You should always override this value.

libdir is automatically detected based on your platform, it should be correct when doing “native” (build machine == host machine) compilation. For cross compiles meson will try to guess the correct libdir, but it may not be accurate, especially on Linux where different distributions have different defaults. Using a cross file, particularly the paths section may be necessary.

Core options

Options that are labeled “per machine” in the table are set per machine. See the specifying options per machine section for details.

OptionDefault valueDescriptionIs per machineIs per subproject
auto_features {enabled, disabled, auto}autoOverride value of all ‘auto’ featuresnono
backend {ninja, vs,
vs2010, vs2015, vs2017, vs2019, xcode}
ninjaBackend to usenono
buildtype {plain, debug,
debugoptimized, release, minsize, custom}
debugBuild type to usenono
debugtrueDebugnono
default_library {shared, static, both}sharedDefault library typenoyes
errorlogstrueWhether to print the logs from failing tests.nono
install_umask {preserve, 0000-0777}022Default umask to apply on permissions of installed filesnono
layout {mirror,flat}mirrorBuild directory layoutnono
optimization {0, g, 1, 2, 3, s}0Optimization levelnono
pkg_config_path {OS separated path}''Additional paths for pkg-config to search before builtin pathsyesno
cmake_prefix_path[]Additional prefixes for cmake to search before builtin pathsyesno
stdsplittrueSplit stdout and stderr in test logsnono
stripfalseStrip targets on installnono
unity {on, off, subprojects}offUnity buildnono
unity_size {>=2}4Unity file block sizenono
warning_level {0, 1, 2, 3}1Set the warning level. From 0 = none to 3 = highestnoyes
werrorfalseTreat warnings as errorsnoyes
wrap_mode {default, nofallback,
nodownload, forcefallback}
defaultWrap mode to usenono
force_fallback_for[]Force fallback for those dependenciesnono

For setting optimization levels and toggling debug, you can either set the buildtype option, or you can set the optimization and debug options which give finer control over the same. Whichever you decide to use, the other will be deduced from it. For example, -Dbuildtype=debugoptimized is the same as -Ddebug=true -Doptimization=2 and vice-versa. This table documents the two-way mapping:

buildtypedebugoptimization
plainfalse0
debugtrue0
debugoptimizedtrue2
releasefalse3
minsizetrues

All other combinations of debug and optimization set buildtype to 'custom'.

Base options

These are set in the same way as universal options, either by -Doption=value, or by setting them inside default_options of project() in your meson.build. However, they cannot be shown in the output of meson --help because they depend on both the current platform and the compiler that will be selected. The only way to see them is to setup a builddir and then run meson configure on it with no options.

The following options are available. Note that they may not be available on all platforms or with all compilers:

OptionDefault valuePossible valuesDescription
b_asneededtruetrue, falseUse -Wl,--as-needed when linking
b_bitcodefalsetrue, falseEmbed Apple bitcode, see below
b_coloroutalwaysauto, always, neverUse colored output
b_coveragefalsetrue, falseEnable coverage tracking
b_lundeftruetrue, falseDon't allow undefined symbols when linking
b_ltofalsetrue, falseUse link time optimization
b_ndebugfalsetrue, false, if-releaseDisable asserts
b_pchtruetrue, falseUse precompiled headers
b_pgooffoff, generate, useUse profile guided optimization
b_sanitizenonesee belowCode sanitizer to use
b_staticpictruetrue, falseBuild static libraries as position independent
b_piefalsetrue, falseBuild position-independent executables (since 0.49.0)
b_vscrtfrom_buildtypenone, md, mdd, mt, mtd, from_buildtypeVS runtime library to use (since 0.48.0)

The value of b_sanitize can be one of: none, address, thread, undefined, memory, address,undefined.

The default value of b_vscrt is from_buildtype. In that case, the following table is used internally to pick the CRT compiler arguments based on the value of the buildtype option:

buildtypeVisual Studio CRT
debug/MDd
debugoptimized/MD
release/MD
minsize/MD
customerror!

Notes about Apple Bitcode support

b_bitcode will pass -fembed-bitcode while compiling and will pass -Wl,-bitcode_bundle while linking. These options are incompatible with b_asneeded, so that option will be silently disabled.

Shared modules will not have bitcode embedded because -Wl,-bitcode_bundle is incompatible with both -bundle and -Wl,-undefined,dynamic_lookup which are necessary for shared modules to work.

Compiler options

Same caveats as base options above.

The following options are available. They can be set by passing -Doption=value to meson. Note that both the options themselves and the possible values they can take will depend on the target platform or compiler being used:

OptionDefault valuePossible valuesDescription
c_argsfree-form comma-separated listC compile arguments to use
c_link_argsfree-form comma-separated listC link arguments to use
c_stdnonenone, c89, c99, c11, c17, c18, c2x, gnu89, gnu99, gnu11, gnu17, gnu18, gnu2xC language standard to use
c_winlibssee belowfree-form comma-separated listStandard Windows libs to link against
c_thread_count4integer value ≥ 0Number of threads to use with emcc when using threads
cpp_argsfree-form comma-separated listC++ compile arguments to use
cpp_link_argsfree-form comma-separated listC++ link arguments to use
cpp_stdnonenone, c++98, c++03, c++11, c++14, c++17, c++2a
c++1z, gnu++03, gnu++11, gnu++14, gnu++17, gnu++1z, gnu++2a,
vc++14, vc++17, vc++latest
C++ language standard to use
cpp_debugstlfalsetrue, falseC++ STL debug mode
cpp_ehdefaultnone, default, a, s, scC++ exception handling type
cpp_rttitruetrue, falseWhether to enable RTTI (runtime type identification)
cpp_thread_count4integer value ≥ 0Number of threads to use with emcc when using threads
cpp_winlibssee belowfree-form comma-separated listStandard Windows libs to link against
fortran_stdnone[none, legacy, f95, f2003, f2008, f2018]Fortran language standard to use

The default values of c_winlibs and cpp_winlibs are in compiler-specific argument forms, but the libraries are: kernel32, user32, gdi32, winspool, shell32, ole32, oleaut32, uuid, comdlg32, advapi32.

All these <lang>_* options are specified per machine. See below in the specifying options per machine section on how to do this in cross builds.

When using MSVC, cpp_eh=none will result in no exception flags being passed, while the cpp_eh=[value] will result in /EH[value]. Since 0.51.0 cpp_eh=default will result in /EHsc on MSVC. When using gcc-style compilers, nothing is passed (allowing exceptions to work), while cpp_eh=none passes -fno-exceptions.

Since 0.54.0 The <lang>_thread_count option can be used to control the value passed to -s PTHREAD_POOL_SIZE when using emcc. No other c/c++ compiler supports this option.

Specifying options per machine

Since 0.51.0, some options are specified per machine rather than globally for all machine configurations. Prefixing the option with build. just affects the build machine configuration, while unprefixed just affects the host machine configuration, respectively. For example:

  • build.pkg_config_path controls the paths pkg-config will search for just native: true dependencies (build machine).

  • pkg_config_path controls the paths pkg-config will search for just native: false dependencies (host machine).

This is useful for cross builds. In the native builds, build = host, and the unprefixed option alone will suffice.

Prior to 0.51.0, these options just effected native builds when specified on the command line, as there was no build. prefix. Similarly named fields in the [properties] section of the cross file would effect cross compilers, but the code paths were fairly different allowing differences in behavior to crop out.

Specifying options per subproject

Since 0.54.0 default_library and werror built-in options can be defined per subproject. This is useful for example when building shared libraries in the main project, but static link a subproject, or when the main project must build with no warnings but some subprojects cannot.

Most of the time this would be used either by the parent project by setting subproject's default_options (e.g. subproject('foo', default_options: 'default_library=static')), or by the user using the command line -Dfoo:default_library=static.

The value is overriden in this order:

  • Value from parent project
  • Value from subproject's default_options if set
  • Value from subproject() default_options if set
  • Value from command line if set

Since 0.56.0 warning_level can also be defined per subproject.