Options handling overhaul breaks backward compatibility

[dnicolodi]

In meson-python we pass some opinionated options to meson setup to tailor the project configuration to the users expectations when building a Python package. Among other things, we pass the -Db_ndebug=if-release options. AFAIU, b_ndebug is not recognized as a valid option when project() does not specify at least one language or one is added with add_languages().

There may be good reasons for this change. However, in meson-python we want to be able to keep passing the -Db_ndebug option. Is there is a way to know before hand if it is a valid option?

Funny enough, if the project is configured without the -Db_ndebug option, and then reconfigured with it, the option is recognized as valid regardless of the project configuring a language or not.

$ meson setup build/ -Db_ndebug=if-release
The Meson build system
Version: 1.7.99
[...]

meson-python undefined

  User defined options
    b_ndebug: if-release


ERROR: Unknown options: "b_ndebug"

A full log can be found at /Users/daniele/src/meson-python/build/meson-logs/meson-log.txt
$ meson setup build/
The Meson build system
Version: 1.7.99
[...]
Found ninja-1.12.1 at /usr/local/bin/ninja
$ meson setup build/ --reconfigure -Db_ndebug=if-release
The Meson build system
Version: 1.7.99
[...]
meson-python undefined

  User defined options
    b_ndebug: if-release

Found ninja-1.12.1 at /usr/local/bin/ninja
$ 

[bonzini]

Would it be possible for you to write a unit test?

[bonzini]

Related to #12923

[jpakkane]

Does the linked MR fix this for you?

[dnicolodi]

It does. Thank you.

[dnicolodi]

I've just run into a variation of the same issue:

$ meson setup build/ -Db_ndebug=if-release
$ rm -r build/meson-private/coredata.dat
$ meson setup build/ -Db_ndebug=if-release
The Meson build system
Version: 1.7.99
[...]
  File "/Users/daniele/src/meson-python/lib/python3.11/site-packages/mesonbuild/options.py", line 1353, in initialize_from_top_level_project_call
    assert isinstance(keystr, str)
           ^^^^^^^^^^^^^^^^^^^^^^^
AssertionError

meson.build:5:0: ERROR: Unhandled python exception

    This is a Meson bug and should be reported!

This used to work as meson uses (used?) the presence of meson-private/coredata.dat as an indication of whether the build directory is initialized or not. Adding --reconfigure to the last meson invocation does not change the result. The presence of the -Db_ndebug=if-release argument is necessary to reproduce the issue.

[eli-schwartz]

Does the linked MR fix this for you?

@jpakkane note that you need to have the "closes #xxxx" on a separate line or the MR will not be linked, only the commit, and then it becomes awkward to reverse-engineer where the discussion happened.

[jpakkane]

I'm not sure if "deleting random undocumented things from the build dir and expecting thing X to happen" is a thing our backwards compatibility guarantee covers. If this can be replicated with "regular" operations then that is of course a different thing.

Priority for fixing this is low.

[dnicolodi]

The issue is relevant because it shows hat Meson is not able anymore to recover from a build directory in an inconsistent state. How you get to the inconsistent state is not that relevant, IMHO. It looks like the same code path is triggered if the build directory is created with another version of Meson, as reported in #14253. This is just an easier way to reproduce the issue.

[bonzini]

@dnicolodi can you reproduce it for example by forcing CoreData.load to raise a MesonException?