Follow-up Comment #2, bug #64746 (project make):
That explanation was really helpful. I discovered the difference between
recursively expanded variables and simple expanded variables only after
posting this issue, but I was still confused why recursive expanded variables
would cause this behavior.
[comment #1 comment #1:]
> Prefer simply expanded variables with $(shell).
>
> Given that sush questions keep arising, maybe we should update NEWS with a
warning about recursively expanded variables in combination with $(shell).
Yes, I think that's a great idea.
I'd also like to add a little more context about my use case: I use this to
read an .env file and then define variables that are still undefined.
-include .env
export
BUILD_OS ?= $(shell uname -s)
...
Up until 4.4 this wasn't a problem because $(shell) didn't see exported
variables. What I'd like to have in 4.4 would be "conditional simple
expansion" from a new ?:= operator that works like this:
ifeq ($(origin VAR_1), undefined)
VAR_1 := $(shell echo 1)
endif
Until then I can use the verbose form from above, or I could introduce
another variable to do it in two lines:
VAR_1_ := $(shell echo 1)
VAR_1 ?= ${VAR_1_}
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64746>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
