Re: exported vs command line variables

[David Boyce]

First I'm going to disagree, a bit with myself and a bit with Philip, because I had not focused sufficiently on the keyword "environment" in "Macros defined by the MAKEFLAGS _environment_ variable ... shall not be added to the environment". While the behavior of setting MAKEFLAGS in the makefile may be undefined, its behavior when encountered in environment seems to be made clear by this statement and GNU make still seems wrong there:

% cat Makefile

all:; env | grep ^WUR ||:

% make -s

%

% MAKEFLAGS=WURGLE=12 make -s

WURGLE=12

Second, I agree with Paul that even when set in the makefile MAKEFLAGS should still not export by default. Partly because understanding and explaining the fine distinctions here could become a full time job and partly because the more ways to pass variables to sub-makes without exporting them the better.

David

On Sat, Sep 24, 2016 at 7:00 AM, Paul Smith <address@hidden> wrote:

On Fri, 2016-09-23 at 16:09 -0700, David Boyce wrote:
> "Macros defined by the MAKEFLAGS environment variable and macros
> defined in the makefile(s) shall not be added to the environment of
> make if they are not already in its environment."

That text is not in the currently published version of the standard
(2008), so it's not normative (yet).  It's a change in behavior from the
current version.  I'm not sure I even have access to the draft.

However, I'm open to making this change as it doesn't seem like much of
an issue from a backwards-compatibility standpoint even though, as
Philip points out, the behavior of make when MAKEFLAGS is set in the
makefile is not specified.

On Fri, 2016-09-23 at 13:24 +0000, Edward Welbourne wrote:
> This does seem like an unsound choice, for the reasons David gave,

Perhaps but as discussed, it's been that way in GNU make (and other
versions of make) forever and is required by the POSIX standard.  So
we'll just have to live with it.