Re: Handling of MAKEFLAGS

[Paul Smith]

On Wed, 2024-01-10 at 17:20 -0500, Dmitry Goncharov wrote:
> > As an example, for the -e change I experimented with simply going
> > through the variable database and switching the origin from o_env
> > to o_env_override or vice versa.
> 
> Do you mean an alternative fix for
> https://savannah.gnu.org/bugs/?64803?
> Do i understand your idea correctly that you want to import all env
> variables as usual with origin o_env and then decode switches and
> then look if -e was specified and then go through the db and replace
> o_env with o_env_override?

Correct.  In fact I implemented this and it worked... except that some
of your test cases (I really appreciate your attention to detail
writing tests; I know it can be a thankless task so I definitely want
to remember to say "thank you"! :)) failed.

Investigating why I discovered the issue was as I mentioned below; once
we have set the flag for -e (the env_overrides global variable) there's
no way to unset it.

> > This works great EXCEPT that if we disable the -e option via
> > MAKEFLAGS, it doesn't actually change the global setting back
> > again; a switch only "enables" but the _lack_ of a switch never
> > "disables".
> 
> right.
> 
> > 
> > In order to make this work we'd need to have a way to reset the
> > global settings to their default values.
> 
> Here, i lost track. What do you mean by "this"? Do you mean replacing
> o_env with o_env_override?

Sorry, I rambled a bit there.

What I was thinking was that the handling of MAKEFLAGS would be changed
so that the content of the MAKEFLAGS variable would be considered the
source of truth, and the values of the global variables set by the
command_switch array etc. would only be convenient shortcuts for that
information.

In particular, every time MAKEFLAGS is changed we would first _reset_
all the global variables back to their default values effectively
undoing whatever settings were made by the previous value of MAKEFLAGS,
then we would re-parse MAKEFLAGS from scratch and set whatever values
were there.

By doing this we would ensure that, for example, if you have:

   MAKEFLAGS += -e

   MAKEFLAGS := $(subst e,,$(word 1,$(MAKEFLAGS))) \
                  $(wordlist 2,$(words $(MAKEFLAGS),$(MAKEFLAGS))

then after the first MAKEFLAGS assignment we'd reset the global option
variables to their default (env_override = 0), then parse MAKEFLAGS
which sets env_override = 1.

Then after the second MAKEFLAGS assignment we'd reset the global option
variables to their default so env_override = 0, then after we parse
MAKEFLAGS the "e" option is not set anymore and env_override is left 0.

After all that, we can go through the variables and reset the override
status o_override vs. o_env_override if the value changed.  Or, maybe
there's a better way to handle that; maybe for example we should
consider chaining variable sets like we do for target-specific
variables and inheritance, and keeping environment variables in a
different set and swapping the order of "env" vs "make" variable sets.
But this might be complicated, there are some special cases for
handling the global set.

Since I actually consider -e to be a terrible feature and would never
consider using it myself, maybe it's better to do the stupid, simple
thing and just go through all the variables and reset them :)