Unable to change any options when using `--reconfigure`, even though output shows they were changed

[andy5995]

Describe the bug When I attempt to change c_args using --reconfigure, there is no change.

To Reproduce

When I use something like: meson gcc-build -Dc_args=-fno-common --reconfigure c_args doesn't change. I ran meson configure gcc-build to verify. Also tried with CFLAGS=-fno-common meson gcc-build --reconfigure but got the same result.

system parameters

• native build
• Debian 10
• Python 3.7.3
• 0.54.2
• ninja 1.8.2

[scivision]

The design goal of --reconfigure is to work as you say: https://github.com/mesonbuild/meson/pull/4077

Except, I'm not sure about c_flags which is a reserved variable.

What I found for Fortran was that:

1. FFLAGS=-fimplicit-none meson build
2. FFLAGS= meson build --reconfigure

The FFLAGS did not clear out--I had to meson build --wipe to get rid of FFLAGS.

However, doing

1. meson -Dfortran_args=-fimplicit-none build
2. meson -Dfortran_args='' build

the fortran_args did reset as expected.

So maybe this is environment variable specific?

[TheQwertiest]

Wait, I thought that reconfigure doesn't actually change any arguments (aside from re-initializing the default ones and/or adding missing values of new options)? And it's the job of meson configure to change values of existing options. I.e. meson setup --reconfigure --c_args=my_arg won't and shouldn't work, but meson configure --c_args=my_arg should.

[xclaesse]

Hmm, gave it a try and this is indeed broken, wondering if that's a regression or if it never worked. Needs to be fixed IMHO.

[nanthony21]

The same issue occurs for cpp_std. Once a build folder is configure the first time you can change cpp_std to anything you want and it will have no effect. Meson will also not raise an error if the value of cpp_std is not valid.

[andy5995]

May be related to https://github.com/mesonbuild/meson/issues/9813?

[andy5995]

Wait, I thought that reconfigure doesn't actually change any arguments (aside from re-initializing the default ones and/or adding missing values of new options)? And it's the job of meson configure to change values of existing options. I.e. meson setup --reconfigure --c_args=my_arg won't and shouldn't work, but meson configure --c_args=my_arg should.

I see. imo, it doesn't seem very intuitive that 'configure' and '--reconfigure' should have such different behavior in cases like that.

That opinion aside, I am able to change 'c_args' by using meson configure -Dc_args=... (though as I reported in #9813, when trying to change c_args with --reconfigure, meson reports that it's been changed, when it actually hasn't been).

@nanthony21 Are you able to change 'cpp_std' by using configure?

@xclaesse Can you also confirm if just using configure works for you?

[andy5995]

Ah.. reviewing this ticket again, I see that @scivision mentioned:

The design goal of --reconfigure is to work as you say: #4077

[eli-schwartz]

May be related to #9813?

That looks like it's a duplicate of this one?

[andy5995]

@eli-schwartz , as far I can tell so far, 9813 is the cause of this issue. In which case, we might consider closing this one, as it would probably be impractical to have an issue opened for every option that's affected by 9813.

[eli-schwartz]

You are the original reporter of this ticket, and as such GitHub empowers you to edit the title from "c_args" to "any options".

[bruce-richardson]

This issue has been encountered by some building the DPDK project (http://dpdk.org) using meson. However, on investigation, I don't see the issue applying to all options - only some of them.

For example, working with -Doptimization= flag seems to work in testing (disable_drivers is DPDK option added for speeding up the build only):

$ meson -Ddisable_drivers=net/* -Doptimization=2 build                                                 
...
$ ninja -C build                                                                                          
<builds as expected>                                                                                    
                                                                                                        
$ meson --reconfigure -Doptimization=3 build                                                              
...
$ ninja -C build                                                                                          
<builds as expected>

However, running the same set of commands using the b_sanitize= option doesn't seem to go as well:

$ meson -Ddisable_drivers=net/* -Db_sanitize=address build                                                
$ ninja -C build                                                                                          
<builds as expected>                                                                                    
                                                                                                        
$ meson --reconfigure -Db_sanitize=thread build                                                           
$ ninja -C build                                                                                          
ninja: Entering directory `build'                                                                       
ninja: no work to do. 

I also note (as commented above too for other flags) that the parameter to sanitize is not being checked on reconfigure. meson --reconfigure -Db_sanitize=everything returns no errors.

[jhgorse]

Ran into an issue regenerating the initial setup configuration trying to change c_std because of a warning about doing it in cflags. Okay, so I find c_std variable which is not builtin like c_flags, but needs embedded in the project(default_options: []).

This reconfigure command meson setup builddir --reconfigure does not work as its suggested when you run meson setup builddir when builddir already exists.

The Principle of Least Surprise Options are either 1) always blow away the builddir configuration when setup is run, keeping meson.build and the builddir in sync, or 2) always blow away builddir configuration when --reconfigure is spec'd and builddir exists.

I do not yet see a good reason to keep the meson.build out of sync with its generated output. In fact, when the meson.build files change, the generated build files should detect that and automatically regenerate that before launching the build.

If there is any interest, I'm happy to submit a feature/change request ticket. And then do the pr. Onward.

Cheers, Joe

[eli-schwartz]

I do not yet see a good reason to keep the meson.build out of sync with its generated output.

They will definitely be out of sync if one thing is specified as the default in the meson.build and another thing is specified on the configure command line. At the very least, it's out of the question to reset the setting back to what the default_options are, if you don't first start tracking the origins of a setting's value in order to tell which were set on the command line and which were set from a default_options.

(Yes, this is another way of saying that the topic has come up several times before and there are definitely people interested in making meson behave the way you suggest, and implementation wise the thing I just suggested is a hard requirement for what is otherwise a plausible suggested enhancement. I'm not aware of anyone working on it at this time.)

In fact, when the meson.build files change, the generated build files should detect that and automatically regenerate that before launching the build.

We already do this. If meson.build files are edited they cause ninja to mark build.ninja as out of date and have it run the REGENERATE_BUILD rule before proceeding.

[jhgorse]

Eli,

Thank you for the note.

If I am reading this right, the hard requirement is that command line options passed to meson setup need to persist. It would make sense to dump the relevant configuration parameters and their origin. I think the priority from highest to lowest is: command line, cross file, native file, meson.build file?

In a quick test, it seems that the REGENERATE_BUILD rule does not consider the default_options : ['c_std=c2x', 'cpp_std=c++11'].

Cheers, Joe

[jorickert]

This seems to be on purpose: https://mesonbuild.com/FAQ.html#why-are-changes-to-default-project-options-ignored

[oscarbenjamin]

It seems after reading the above that --reconfigure does not do what I thought it would do from the name. It is unclear to me exactly what its purpose is or when I would use it.

Basically I had hoped that:

meson configure build --reconfigure -Dfoo=bar

would be functionally equivalent to

rm -r build
meson setup build -Dfoo=bar

How would I get the intended effect of configuring the build directory as if it was being configured from scratch but without needing to build everything from scratch if nothing has really changed?

Would it make sense to have a meson reconfigure command that does this?

I am thinking of situations like git bisect where I want to build many times as if I am building from fresh but it would be great to have incremental rebuilds in so far as that is possible. Potentially I would be bisecting to find that a changed default option is the trigger of a bug but I need to make sure that I am using the default options each time I checkout a new commit to discover that.

[dcbaker]

Unless you're bisecting Meson itself, you shouldn't need to reconfigure from scratch across a bisect like that. Meson, if working correctly, should have configured ninja in such a way that only the things that have changed across the bisect are rebuilt, including re-running Meson if necessary. When you run meson configure build -Dfoo=bar the Meson state becomes dirty, and the next time ninja is invoked then meson should reconfigure.

If you are running into cases where this doesn't work, you probably want meson setup --wipe (not sure if you can pass -D arguments with --wipe). Please also open an issue because that is Meson not behaving correctly

[eli-schwartz]

The question is how to bisect the fact that project(..., default_options: ['importantsetting=frob']) has changed its value and caused an issue to occur.

A related question is whether that is something that falls under "bisecting". I can hear arguments both ways.

[oscarbenjamin]

I can see it both ways as well but at least there could be some way to obtain a reproducible configuration which is why I suggested meson reconfigure.

Here I have an option:

option('someoption', type: 'combo', choices: ['A', 'B', 'C'], value: 'A')

We can see it is set to A after setup:

$ meson setup build-dir
$ meson configure build-dir
...
  Project options    Current Value        Possible Values      Description                           
  -----------------  -------------        ---------------      -----------                           
  someoption         A                    [A, B, C]            someoption 

I can change the option to C:

$ meson configure build-dir/ -Dsomeoption=C
$ meson configure build-dir
...
  Project options    Current Value        Possible Values      Description                           
  -----------------  -------------        ---------------      -----------                           
  someoption         C                    [A, B, C]            someoption 

With --wipe I get:

$ meson setup build-dir/ --wipe
...
  User defined options
    someoption: C
...
$ meson configure build-dir
...
  Project options    Current Value        Possible Values      Description                           
  -----------------  -------------        ---------------      -----------                           
  someoption         C                    [A, B, C]            someoption

I though this was what --reconfigure might do but apparently not:

$ meson setup build-dir --reconfigure
...
  User defined options
    someoption: C
...

How can I get back to the default value A?

I know that I can do meson configure build-dir -Dsomeoption=A but I want to restore all options to their defaults as they would be after meson setup build-dir. I want to feel that I can trust that the resulting build is equivalent to what I would have got if I had built everything from scratch. I can achieve the configuration I want with rm -r build-dir && meson setup build-dir but then I need to rebuild everything from scratch.

Using meson setup build-dir --wipe seems to be the opposite of what I wanted:

• After --wipe all of the built files are deleted and I have to rebuild everything.
• After --wipe the option is still set to C rather than the default A.

What I am looking for is the reverse of this:

• Don't delete the built files.
• Reset all configuration options to defaults.

In context there is a good chance that I might already be in the default configuration but I want to run e.g. meson reconfigure just to be sure. It would even be useful if reconfigure could tell me exactly which options it changed and what the old and new values were.