[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul D. Smith
Subject: [bug #63347] make 4.4 change in behavior for sub-make invoked via $(shell)
Date: Fri, 11 Nov 2022 16:39:32 -0500 (EST)

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
  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

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 :=


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

$ make CONF_VAR=bar
called target 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:


Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]