diff options
Diffstat (limited to 'docs/markdown/Builtin-options.md')
| -rw-r--r-- | docs/markdown/Builtin-options.md | 179 |
1 files changed, 96 insertions, 83 deletions
diff --git a/docs/markdown/Builtin-options.md b/docs/markdown/Builtin-options.md index 23995dc..189204f 100644 --- a/docs/markdown/Builtin-options.md +++ b/docs/markdown/Builtin-options.md @@ -11,19 +11,24 @@ 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`. +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. +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`. +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` +* 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 @@ -44,21 +49,22 @@ Installation options are all relative to the prefix, except: | sysconfdir | etc | Sysconf data directory | -`prefix` defaults to `C:/` on Windows, and `/usr/local` otherwise. You should always -override this value. +`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](Cross-compilation.md#defining-the-environment), -particularly the paths section may be necessary. +`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](Cross-compilation.md#defining-the-environment), 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](#specifying-options-per-machine) section -for details. +Options that are labeled "per machine" in the table are set per +machine. See the [specifying options per +machine](#specifying-options-per-machine) section for details. | Option | Default value | Description | Is per machine | Is per subproject | | ------ | ------------- | ----------- | -------------- | ----------------- | @@ -82,13 +88,13 @@ for details. | wrap_mode {default, nofallback,<br>nodownload, forcefallback, nopromote} | default | Wrap mode to use | no | no | | force_fallback_for | [] | Force fallback for those dependencies | no | no | -<a name="build-type-options"></a> -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: +<a name="build-type-options"></a> 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: | buildtype | debug | optimization | | --------- | ----- | ------------ | @@ -102,15 +108,16 @@ 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. +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: +The following options are available. Note that they may not be +available on all platforms or with all compilers: | Option | Default value | Possible values | Description | | ----------- | ------------- | --------------- | ----------- | @@ -131,10 +138,11 @@ platforms or with all compilers: The value of `b_sanitize` can be one of: `none`, `address`, `thread`, `undefined`, `memory`, `address,undefined`. -<a name="b_vscrt-from_buildtype"></a> -The default value of `b_vscrt` is `from_buildtype`. The following table is used -internally to pick the CRT compiler arguments for `from_buildtype` or -`static_from_buildtype` *(since 0.56)* based on the value of the `buildtype` option: +<a name="b_vscrt-from_buildtype"></a> The default value of `b_vscrt` +is `from_buildtype`. The following table is used internally to pick +the CRT compiler arguments for `from_buildtype` or +`static_from_buildtype` *(since 0.56)* based on the value of the +`buildtype` option: | buildtype | from_buildtype | static_from_buildtype | | -------- | -------------- | --------------------- | @@ -147,21 +155,22 @@ internally to pick the CRT compiler arguments for `from_buildtype` or ### 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. +`-Wl,-bitcode_bundle` while linking. These options are incompatible +with `b_asneeded`, so that option will be silently disabled. -[Shared modules](Reference-manual.md#shared_module) 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. +[Shared modules](Reference-manual.md#shared_module) 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: +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: | Option | Default value | Possible values | Description | | ------ | ------------- | --------------- | ----------- | @@ -180,56 +189,60 @@ compiler being used: | cpp_winlibs | see below | free-form comma-separated list | Standard Windows libs to link against | | fortran_std | none | [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. +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](#specifying-options-per-machine) section on -how to do this in cross builds. +All these `<lang>_*` options are specified per machine. See below in +the [specifying options per machine](#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`. +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. +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: +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). + - `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). + - `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. +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. +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. +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`. +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 overridden in this order: - Value from parent project |