meson: Silently ignoring changes to default_options in project() is a bad user experience

This has come up repeatedly, most recently when @pwithnall saw CI failures that didn’t get fixed when he added c_std=c99 to default_options because we silently ignore changes to it on reconfigure.

Our options are:

Change the outputted build.ninja to contain changes to default_options (tricky; f.ex what if default_options changes a value that the user had previously set on the command-line?)
Warn that default options were changed, and users should run ninja wipe-reconfigure (which is a target that we’ve talked about which would wipe all meson configuration and re-configure from scratch)

The current situation is somewhat bad, IMO.

About this issue

Original URL
State: open
Created 7 years ago
Comments: 22 (19 by maintainers)

Most upvoted comments

I just stumbled upon this lately, and as other say I don’t think this behavior makes sense. I expect meson setup --reconfigure to be “generate build.ninja as if we were starting fresh (but do reuse build artifacts if they’re built with the same arguments), except remember all the command line flags that have been passed in before”.

I don’t get the argument about “convergence” in https://github.com/mesonbuild/meson/issues/2193#issuecomment-322566536 either. The way I just described will converge no worse, since it’s mostly stateless except the remembered command line flags.

Is there any reason we can’t move to something like I (and some others) described? The implementation would not be that hard either, as a starting point we can just discard coredata.dat, which is a small hit in reconfigure performance but gives much less hassle.

ishitatsuyuki on Nov 21, 2022

The thing is, as a user I don’t want to call any other command manually after updating my build files. I simply want to call ninja and everything should work and not use old information that I never touched myself.

nioncode on Jan 21, 2019

This is still befuddling noobs (me) several years after the initial report. Is there a best practice for avoiding this extremely confusing problem?

egnor on Dec 20, 2021

meson’s approach has always been that you configure your build dir once and only have to call ninja afterwards. However, this is not true if you modify the default_options of your project. Then you either have to wipe your build dir or also change the option through meson configure.

This is bad user experience. If I never touched the default values, but then change them in my meson.build, I’d expect meson to pick this up and reconfigure accordingly.

nioncode on Jan 20, 2019

Otherwise, somebody has to clean the build directory on the CI or manually update the options in the build directory.

CI should always run from a clean slate. That’s what it’s for and also why CCache was invented.

Then, when the options are changed in meson.build, this flag can be checked to see if the value should be updated from default_options.

Which means that whether something changes value or not is based on hidden state. Which is also an awful user experience.

jpakkane on Jan 20, 2019

Storing the changes and warning (#2 in the post) is workable, we can do that.

Warning is no use for CI unless there’s an option to turn it into a failure. Even better, rather than failing and requiring human intervention to fix (sad times), it would automatically reconfigure.

I don’t really care about the semantics of how options are handled. I pushed a change to git, and it wasn’t reflected in the next CI run. This should be possible to fix without the fix requiring human intervention. 😃

pwithnall on Aug 18, 2017