URL:
<http://savannah.gnu.org/bugs/?46012>
Summary: MAKEFLAGS does not include command overrides if -e
flag is set
Project: make
Submitted by: rici
Submitted on: Mon 21 Sep 2015 02:10:12 GMT
Severity: 3 - Normal
Item Group: Bug
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
Component Version: 4.1
Operating System: POSIX-Based
Fixed Release: None
Triage Status: None
_______________________________________________________
Details:
Command overrides are passed to child processes, including sub-makes, as
environment variables; for sub-makes they are also placed into MAKEFLAGS,
which is effectively the same as making them command overrides in the
sub-make.
However, if the --environment-overrides flag is set, command overrides are not
passed through MAKEFLAGS. Normally, this doesn't matter too much since they
are still passed through the environment, but the difference is visible and in
some cases surprising.
This is a regression from 3.8. See the analysis below.
---
Makefile:
ifeq "$(MAKELEVEL)" "0"
all:
@echo outer: 'foo is "$(foo)" from $(origin foo)'
@$(MAKE)
else
all:
@echo inner: 'foo is "$(foo)" from $(origin foo)'
endif
---
output of `make -s foo=override`:
outer: foo is "override" from command line
inner: foo is "override" from command line
---
output of `make -s -e foo=override`:
outer: foo is "override" from command line
inner: foo is "override" from environment
---
This becomes slightly more irritating in combination with the override
modifier. Suppose we change the Makefile to augment the value of foo by adding
`override foo+=added`. Now foo is *not* exported to the environment (because
it now has origin "file", and only "command" and "env" origin variables are
exported by default), and the effect of the -e command line flag is
unexpected.
Makefile:
ifeq "$(MAKELEVEL)" "0"
override foo+=added
all:
@echo outer: 'foo is "$(foo)" from $(origin foo)'
@$(MAKE)
else
all:
@echo inner: 'foo is "$(foo)" from $(origin foo)'
endif
---
Output of `make -s foo=override`:
outer: foo is "override added" from override
inner: foo is "override" from command line
---
Output of `make -s -e foo=override`:
outer: foo is "override added" from override
inner: foo is "" from undefined
---
This is a consequence of
http://git.savannah.gnu.org/cgit/make.git/commit/main.c?id=2627d8322136eac2b499dd12e2769eb01d7c74bc,
where a comment shows the long history of the origin of MAKEFLAGS (main.c line
3150)
/* This used to use o_env, but that lost when a makefile defined MAKEFLAGS.
Makefiles set MAKEFLAGS to add switches, but we still want to redefine
its value with the full set of switches. Then we used o_file, but that
lost when users added -e, causing a previous MAKEFLAGS env. var. to take
precedence over the new one. Of course, an override or command
definition will still take precedence. */
v = define_variable_cname ("MAKEFLAGS", flagstring,
env_overrides ? o_env_override : o_file, 1);
The origin of MAKEFLAGS is important, because it controls whether or not the
value of MAKEFLAGS will be recursively expanded before exporting it.
(variable.c line 1056):
/* If V is recursively expanded and didn't come from the environment,
expand its value. If it came from the environment, it should
go back into the environment unchanged. */
if (v->recursive
&& v->origin != o_env && v->origin != o_env_override)
{
char *value = recursively_expand_for_file (v, file);
With the origin of MAKEFLAGS set to o_env_override, it is not recursively
expanded, so the value passed to the environment is "e -- $(MAKEOVERRIDES)"
instead of "e -- foo=override".
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?46012>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
