I think you misunderstood the point of my message. The date doesn't matter here, it was just a random command in a demo makefile. In fact the command was originally "hostname" but I was concerned about leaking even the smallest amount of internal data about my workplace so I figured "date" was safest since the time is public info.
> There could be multiple places where it is needed. When I say "needed" here I mean specifically that the recipe runs. Clearly a target-specific variable is 'needed' iff the target is built. It's not a question of how many places the variable is expanded, it's a boolean thing: the target is built or not built, the target-specific variable is needed or not. David On Tue, Jun 9, 2020 at 8:52 AM Dmitry Goncharov via Bug reports and discussion for GNU make <bug-make@gnu.org> wrote: > On Tue, Jun 9, 2020 at 9:10 AM David Boyce <dbo...@broadcom.com> wrote: > > TARGETS := aa bb cc dd > > $(TARGETS): at := $(shell set -x; date) > > Despite the same name "at" those are different variables. > Given that there are 4 simple variables defined, 4 calls to date take > place. > > $ cat makefile > .PHONY: all > all: aa bb > aa: at := $(shell set -x; date) > $(shell sleep 5) > bb: at := $(shell set -x; date) > aa bb: > @:$(info Making $@ at $(at)) > $ make > + date > + date > Making aa at Tue Jun 9 11:50:08 EDT 2020 > Making bb at Tue Jun 9 11:50:13 EDT 2020 > > Note, aa's at is 5 seconds earlier then bb's. > > > > But in a target-specific context should the variable be considered > "defined" at the time it's parsed or at the time it's needed? > There could be multiple places where it is needed. > > regards, Dmitry > >
