Re: Handling of MAKEFLAGS

[Dmitry Goncharov]

On Wed, Jan 10, 2024 at 5:46 PM Paul Smith <psmith@gnu.org> wrote:
>
> On Wed, 2024-01-10 at 17:20 -0500, Dmitry Goncharov wrote:
>
> 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.

> 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.

You are designing a new feature, aren't you? Specifically, the ability
to unset -e.
If really needed, a makefile can reset -e on the command line for
submake and have submake do the work.
Alternatively, it is possible to introduce the opposite switch, just
like -S and -k.


> 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.

i agree that the makeflags business is overly complex. i feel, the
main issue is that makeflags serves two functions, it carries command
line switches to submake and it allows a makefile to set switches.
This ability to set switches is the cause of the complexity.
Instead of
MAKEFLAGS+=-R

i'd rather introduce a function like
$(toggle_switch R, 1) # Set -R.
$(toggle_switch R, 0) # Reset -R.

However, this ship sailed 30 years ago.


> 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 :)

i like this better, as long as the behavior matches the manual.

regards, Dmitry