Re: Handling of MAKEFLAGS

2024-01-28 Thread Paul Smith
On Thu, 2024-01-11 at 00:37 -0500, Dmitry Goncharov wrote: > 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

Re: Handling of MAKEFLAGS

2024-01-10 Thread Dmitry Goncharov
nset 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 sh

Re: Handling of MAKEFLAGS

2024-01-10 Thread Paul Smith
uot;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 "

Re: Handling of MAKEFLAGS

2024-01-10 Thread Dmitry Goncharov
On Tue, Jan 9, 2024 at 5:35 PM Paul Smith wrote: > Hi Dmitry; Good morning, Paul. > 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

Handling of MAKEFLAGS

2024-01-09 Thread Paul Smith
"disables". In order to make this work we'd need to have a way to reset the global settings to their default values. This means we'd need to reapply all the settings. So I wondered if maybe it wouldn't be worthwhile to change the handling of MAKEFLAGS so the value of MAKEFLAGS was considered