[bug #46012] MAKEFLAGS does not include command overrides if -e flag is set

[Rici Lake]

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/