Handling Meson build options with multiple buildtypes

Question

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?

Jerusalem

It turn out meson -Dcpp_args=-ffoo does not even work for cross-compiler situations, but the cpp_args can be specified within the cross compiler file, which adds a bit more complexity to the issue. – Jerusalem

Is it possible to specify build type (debug/release) for executable or it has to be specified for project? (And if it possible to specify only for executable is the option applied on dependent libraries as well?) – Interglacial

@Interglacial It would be preferred to have the build type for the whole project... but if you've got a solution for just an executable, I'd like to hear it too. – Jerusalem

Answer 1

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.

Shellyshelman

1. This is unfortunate.. the use case is to set up an IDE to set build type to "debug" and build, whether or not the build-debug directory already exists, as well as set build type to "release" and build. So meson configure offers nothing over the command line meson way I suggested in the question. You have to put all the buildtype-specific options into the command line, and not into the file. For me, a file is easier to have as a project template than a command line. – Jerusalem

2. Thanks, the ['b_ndebug=if-release'] is nice, but unfortunately not generalised. I want b_lto to be enabled for releases only, but there is no if-release option. b_ndebug can go in the file therefore, but b_lto has to remain on the command line. – Jerusalem

Not sure what you mean by "always portable", because meson -Dfoo would not invoke gcc -Dfoo. – Jerusalem

3. For b_sanitize, this is not true that it detects properly automatically if it is supported. For example, I have a Xilinx baremetal OS GCC toolchain in which the compiler accepts -fsanitize, but there are no sanitizer libraries available for the linker to link. Meson in this case thinks b_sanitize is fine to enable, even though it won't link. I even said in the question "because the library might be missing, for example". – Jerusalem

In summary, the answer is that there is no particularly nice way for the use case. – Jerusalem

@JetskiS-type because the library might be missing, for example Then you have to check for library existence using meson.get_compiler('c').find_library(...), not only for option existence. – Shellyshelman

Ok, but can find_library('asan') or whatever be done for the built-in b_sanitize option? Don't think so.... – Jerusalem

For what it's worth, if cc.has_link_argument('-fsanitize=address') as written in the question does actually work, with Meson outputting: Compiler for C supports link arguments -fsanitize=address: NO – Jerusalem

Oh, I understand what you mean now by "always portable": in the Meson script add_project_arguments('-DNDEBUG', language: 'cpp') results in cl /DNDEBUG for MSVC, etc. – Jerusalem