meson
meson copied to clipboard
Conditional options
For some projects of mine I have an option to turn on additional compiler warnings, like -Wpadded (gcc, clang), which usually generate noise but might be interesting to look at occasionally.
I used to include this option only for the supported compilers, but as far as I could gather, options must be defined in meson_options.txt, which does not allow any statement besides option().
It would be nice to be able to nest option()s in conditional branches checking the build environment.
And although I don't have a use-case at hand right now, it seems useful to be able to hide or show certain options depending on the value of other options.
The build environment is not available at the time of option parsing, and cannot be (since it's a circular dependency), so this would be difficult to do. In your case, what I would do is to have a generic additional-warnings boolean option which applies to all build environments, and does nothing when appropriate.
I am also interested in conditional build options. I my case I am only interested changing the build options based on host_machine.system(). This should be available at the time of option parsing.
I want to be able to enable options only on platforms that the option is applicable to. I would also like to be able to change the default value based on the platform. eg an option for font configuration would have a default of of freetype on unix platforms and win32 fonts on windows platforms.
I am interested in the ability to conditionally set the project's default_options.
Backstory: there's this environ symbol that is undefined at shared library link time (comes from the C runtime). Meson defaults to b_lundef=true, which sets -Wl,--no-undefined at shared library link time, so the linker fails with undefined reference to 'environ'. On Linux, access to environ is not necessary for this project's use case, because there's clearenv. So we'd like to have something like this:
project(…
default_options: [
host_machine.system().startswith('linux') ? 'b_lundef=true' : 'b_lundef=false',
],
)
I build the same source in both an embedded system, and hostside. Obviously, there is a cross file for the embedded system. It would be nice if I could, for example, set b_staticpic explicitly off in the cross file, and have the project default to on.
@wasim42 You can do that manually in meson.build by fetching a variable from the [properties] tag of the cross file and setting the option to that property if it's cross compiling like so:
if meson.is_cross_build()
b_staticp = meson.get_cross_property('b_staticp')
else
b_staticp = get_option('b_staticp')
endif
hi everyone. just a friendly ping here to check if there is any update about this topic
This issue predates my involvement, but hmm, you can disable lundef if you know it can't be used, by using override_options rather than changing the default but allowing users to break the build by setting it manually. I actually find this example to be an argument against conditional options (but there are other arguments for it).
It would be nice if I could, for example, set b_staticpic explicitly off in the cross file, and have the project default to on.
Cross files can (these days) include setting built-in or project options. No need for properties anymore.
Hidden options based on the host_system do seem potentially useful, but afaik no one is actively working on this.
thanks for the information @eli-schwartz !
I am interested in the ability to conditionally set the project's
default_options.
I'm interested in this too. My use case is that I want the default build type to be debugoptimized for git checkouts, but release for release tarballs. In our autotools-based setup (I'm starting to convert to meson) we normally have the version set to something like 1.2.3-git-$GIT_HASH, and then when we cut a release, we have a script that removes the suffix. Then we have a conditional in configure.ac that sets the default CFLAGS appropriately for debug or release depending on if the version string has a git hash suffix.
(Although, since we have a script to bump the version for release, I suppose it could also update the default buildtype option as well. But it would be more convenient to not have to do that.)