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/