|Subject:||Re: [bug #60538] Environment variable overrides explicit assignment|
|Date:||Thu, 6 May 2021 17:11:25 +0000|
> The manual doesn't actually say that MAKEOVERRIDES is exported like MAKEFLAGS but I assume it is.
I was going to just say that MAKEFLAGS would be expanded before being exported, and indeed it is, but, having tried it, the results aren't quite what I would have expected, even having just skimmed the section on MAKEOVERRIDES that Paul just cited.
$ make TESTNAME=badger 2>&1 | grep MAKE
MAKEFLAGS= -- TESTNAME=badger
... eliding mentions of MAKE in my environment already...
So MAKEOVERRIDES is exported, though perhaps it doesn't need to be, but isn't expanded before being exported.
From: David Boyce <firstname.lastname@example.org>
Sent: Thursday, May 6, 2021 09:48
To: Paul D. Smith <email@example.com>
Cc: Shareef Jalloq <firstname.lastname@example.org>; Martin Dorey <Martin.Dorey@hitachivantara.com>; Boris Kolpackov <email@example.com>; bug-make <firstname.lastname@example.org>
Subject: Re: [bug #60538] Environment variable overrides explicit assignment
***** EXTERNAL EMAIL *****
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.NOREPLY@gnu.org> wrote:
Update of bug #60538 (project make):
|[Prev in Thread]||Current Thread||[Next in Thread]|