Unable to change any options when using `--reconfigure`, even though output shows they were changed
Opened this issue · 19 comments
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
The design goal of --reconfigure is to work as you say: #4077
Except, I'm not sure about c_flags
which is a reserved variable.
What I found for Fortran was that:
FFLAGS=-fimplicit-none meson build
FFLAGS= meson build --reconfigure
The FFLAGS did not clear out--I had to meson build --wipe
to get rid of FFLAGS.
However, doing
meson -Dfortran_args=-fimplicit-none build
meson -Dfortran_args='' build
the fortran_args did reset as expected.
So maybe this is environment variable specific?
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.
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.
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.
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 ofmeson configure
to change values of existing options. I.e.meson setup --reconfigure --c_args=my_arg
won't and shouldn't work, butmeson 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?
Ah.. reviewing this ticket again, I see that @scivision mentioned:
The design goal of --reconfigure is to work as you say: #4077
May be related to #9813?
That looks like it's a duplicate of this one?
@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.
You are the original reporter of this ticket, and as such GitHub empowers you to edit the title from "c_args" to "any options".
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.
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
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.
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
This seems to be on purpose: https://mesonbuild.com/FAQ.html#why-are-changes-to-default-project-options-ignored
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.
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
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.
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.