Having read the Meson site pages (which are generally high quality), I'm still unsure about the intended best practice to handle different options for different buildtypes.
So to specify a debug build:
meson [srcdir] --buildtype=debug
Or to specify a release build:
meson [srcdir] --buildtype=release
However, if I want to add b_sanitize=address
(or other arbitrary complex set of arguments) only for debug builds and b_ndebug=true
only for release builds, I would do:
meson [srcdir] --buildtype=debug -Db_sanitize=address ...
meson [srcdir] --buildtype=release -Db_ndebug=true ...
However, it's more of a pain to add a bunch of custom arguments on the command line, and to me it seems neater to put that in the meson.build file. So I know I can set some built in options thusly:
project('myproject', ['cpp'],
default_options : ['cpp_std=c++14',
'b_ndebug=true'])
But they are unconditionally set.
So a condition would look something like this:
if get_option('buildtype').startswith('release')
add_project_arguments('-DNDEBUG', language : ['cpp'])
endif
Which is one way to do it, however, it would seem the b_ndebug=true
way would be preferred to add_project_arguments('-DNDEBUG')
, because it is portable.
How would the portable-style build options be conditionally set within the Meson script?
Additionally, b_sanitize=address
is set without any test whether the compiler supports it. I would prefer for it to check first if it is supported (because the library might be missing, for example):
if meson.get_compiler('cpp').has_link_argument('-fsanitize=address')
add_project_arguments('-fsanitize=address', language : ['cpp'])
add_project_link_arguments('-fsanitize=address', language : ['cpp'])
endif
Is it possible to have the built-in portable-style build options (such as b_sanitize
) have a check if they are supported?
Most non-trivial builds require user-settable options. As an example a program may have two different data backends that are selectable at build time. Meson provides for this by having a option definition file.
To get the current list execute meson configure in the build directory. The backend_startup_project option can be set to define the default project that will be executed with the "Start debugging F5" action in visual studio. It should be the same name as an executable target name.
It should be noted that you can not set option values in your Meson scripts. They have to be set externally with the meson configure command line tool. Running meson configure without arguments in a build dir shows you all options you can set. To change their values use the -D option: Setting the value of arrays is a bit special.
Running meson configure without arguments in a build dir shows you all options you can set. To change their values use the -D option: Setting the value of arrays is a bit special. If you only pass a single string, then it is considered to have all values separated by commas.
I'm still unsure about the intended best practice to handle different options for different buildtypes
The intended best practice is to use meson configure
to set/change the "buildtype" options as you need it. You don't have to do it "all at once and forever". But, of course, you can still have several distinct build trees (say, "debug" and "release") to speed up the process.
How would the portable-style build options be conditionally set within the Meson script?
Talking of b_ndebug
, you can use the special value: ['b_ndebug=if-release']
, which does exactly what you want. Also, you should take into account, that several GNU-style command-line arguments in meson
are always portable, due to the internal compiler-specific substitutions. If I remember correctly, these include: -D
, -I
, -L
and -l
.
However, in general, changing "buildtype" options inside a script (except default_options
, which are meant to be overwritten by meson setup/configure
), is discouraged, and meson
intentionally lacks set_option()
function.
Is it possible to have the built-in portable-style build options (such as b_sanitize) have a check if they are supported?
AFAIK, no, except has_argument()
you've used above. However, if some build option, like b_sanitize
, is not supported by the underlying compiler, then it will be automatically set to void, so using it shouldn't break anything.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With