Most likely he thinks/thought that since there are two different make processes with a python process in between the command line override wouldn't leak to the child make. But (from the manual):
> Likewise variables defined on the command line are passed to the sub-make through MAKEFLAGS. (5.7.3) > The special variable MAKEFLAGS is always exported (unless you unexport it). (5.7.2) The manual doesn't actually say that MAKEOVERRIDES is exported like MAKEFLAGS but I assume it is. On Thu, May 6, 2021 at 9:07 AM Paul D. Smith <invalid.nore...@gnu.org> wrote: > Update of bug #60538 (project make): > > Status: None => Not A Bug > > Open/Closed: Open => Closed > > > _______________________________________________________ > > Follow-up Comment #5: > > As Martin says, if the variable is set ON THE COMMAND LINE, it will > absolutely > take precedence over the setting in a makefile variable (unless overridden > with override). > > But, you said you has set this IN THE ENVIRONMENT which is very different; > values set in the environment should not take precedence over values set in > the makefile (as long as -e is not set). > > So, you'll have to investigate why/how this variable assignment is > appearing > in your command line (in MAKEFLAGS). > > I'm going to close this; you can continue to post here but better would be > to > discuss on the mailing list, until/unless we discover a bug. > > Cheers! > > _______________________________________________________ > > Reply to this item at: > > <https://savannah.gnu.org/bugs/?60538> > > _______________________________________________ > Message sent via Savannah > https://savannah.gnu.org/ > > >
