Meson: Instead of just printing a warning, Meson should abort and exit with an error code if an unknown build option is used

[Flowdalic]

Describe the bug
Meson currently only prints an easy to miss, especially in CI builds, warning if an unknown build option has been passed via -D<option-name>=<value>. It may not be that easy to miss if meson configure is used, but it is certainly easy to miss if meson is used to create a build/ directory.

To Reproduce
Invoke meson with an argument that configured an unknown build option. For example.

$ meson -Dfoo=bar build-foo/
The Meson build system
Version: 0.52.1
Source dir: /home/user/code/barproject
Build dir: /home/user/code/barproject/build-foo
Build type: native build
WARNING: Unknown options: "foo"
Project name: barproject
Project version: 0.1
C compiler for the host machine: ccache cc (gcc 9.3.0 "cc (Gentoo 9.3.0 p2) 9.3.0")
C linker for the host machine: GNU ld.bfd 2.33.1
C++ compiler for the host machine: ccache c++ (gcc 9.3.0 "c++ (Gentoo 9.3.0 p2) 9.3.0")
C++ linker for the host machine: GNU ld.bfd 2.33.1
Host machine cpu family: x86_64
Host machine cpu: x86_64
Run-time dependency threads found: YES 
Configuring barproject_config.h using configuration
Found pkg-config: /usr/bin/pkg-config (0.29.2)
Run-time dependency GTest found: YES 1.9.0
Dependency threads found: YES (cached)
Build targets in project: 9
Found ninja-1.9.0.git.kitware.dyndep-1.jobserver-1 at /usr/bin/ninja

Expected behavior
The meson command should abort with an error code.

[codysch]

I have been burned by this recently as well. I think it's helpful to note that the behavior of silently dropping unknown options also affects the default_options block in the meson.build project().

In my case, I was miss-spelling the b_sanitize option, resulting in none of the expected sanitizers being enabled.

[TheQwertiest]

Same here: I've lost count how many times I've misspelled built-in options - pkg_config_path vs pkg-config-path, buildtype vs build_type, b_staticpic vs b_fpic and etc and etc...

[codysch]

Another note: it's worse for b_* options (where I've experienced this) as there is not even a warning emitted. In other words: meson . b -Db_sanitize_not_really=none does not complain at all even though b_sanitize_not_really is bogus.

For options that don't start with b_* (ie: aren't considered builtin options), one can use --fatal-meson-warnings. Unfortunately, this may turn some warnings that are being ignored purposely into errors (In my case, I've needed to support some custom -fsanitize flags to handle native true vs false builds, which results in meson warning that I should use b_sanitize).

[dcbaker]

When I added that warning the plan was to make it fatal. you may be in interested in the --fatal-meson-warnings option, which makes that a hard error.

[jpakkane]

We don't have an established policy for turning new warnings into hard errors, but I'd say that if it has been there for a few full releases we can do it.

[dcbaker]

It's been there a long time, it was one of my first contributions (back around the end of the .3x or early .4x IIRC). I'll go look

[jpakkane]

Well let's go for it then