[bug #63347] make 4.4 change in behavior for sub-make invoked via $(shell)

[Paul D. Smith]

Follow-up Comment #2, bug #63347 (project make):

Yes, this is changed in this release; please see the NEWS file
https://git.savannah.gnu.org/cgit/make.git/tree/NEWS?h=4.4#n74 :

* WARNING: Backward-incompatibility!
  Previously makefile variables marked as export were not exported to
commands
  started by the $(shell ...) function.  Now, all exported variables are
  exported to $(shell ...). [...]


If you don't want a sub-make to receive the command-line overrides, you can
reset it via `MAKEOVERRIDES`; see
https://www.gnu.org/software/make/manual/html_node/Options_002fRecursion.html

An option that I _think_ does what you want might be:


get_conf_var = $(shell $(MAKE) -C lib -s get_conf_var)

all: $(get_conf_var)
        @echo $(get_conf_var)

all: private MAKEOVERRIDES :=


Result:

$ make --version | head -n1
GNU Make 4.4

$ make CONF_VAR=bar
called target foo
CONF_VAR=bar
get_conf_var=foo


Another option you can use to be more specific BUT which requires GNU Make 4.4
and won't work with earlier versions is to use the new *let* function
https://www.gnu.org/software/make/manual/html_node/Let-Function.html :

get_conf_var = $(shell $(MAKE) -C lib -s get_conf_var)

all: $(get_conf_var)
        @echo $(let MAKEOVERRIDES,,$(get_conf_var))


Personally I think that relying on this odd quirk of shell behavior is hard
for people to understand, especially in the old behavior where you got
different results from running the shell function in different contexts.  It
seems to me that finding a better way that made this requirement more explicit
would be much cleaner.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63347>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/