Re: simple assignment of target-specific variables
On Tue, Jun 09, 2020 at 09:36:43AM -0700, David Boyce wrote: > On Tue, Jun 9, 2020 at 9:21 AM Dmitry Goncharov > wrote: > > You mean for target specific simple variable memory is allocated and > > the variable is initialized only if the target is built, right? > Yes, that's the suggestion I was making though I don't know the innards of > make well enough to know how hard it would be. After further thinking i came to the following example. a:=1 bat: wom:=$(a) a:=2 bat:; @echo wom=$(wom) If make postpones initialization of wom until bat recipe has to run then the value of wom will be 2. This would be a breaking change. regards, Dmitry
Re: simple assignment of target-specific variables
Yes, that's the suggestion I was making though I don't know the innards of make well enough to know how hard it would be. David On Tue, Jun 9, 2020 at 9:21 AM Dmitry Goncharov wrote: > On Tue, Jun 9, 2020 at 12:01 PM David Boyce > wrote: > > 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. > > You mean for target specific simple variable memory is allocated and > the variable is initialized only if the target is built, right? > Looks reasonable to me. > > regards, Dmitry >
Re: simple assignment of target-specific variables
On Tue, Jun 9, 2020 at 12:01 PM David Boyce wrote: > 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. You mean for target specific simple variable memory is allocated and the variable is initialized only if the target is built, right? Looks reasonable to me. regards, Dmitry
Re: simple assignment of target-specific variables
On Tue, Jun 9, 2020 at 9:46 AM Edward Welbourne wrote: > I presume the workaround is > > TGTDATE := $(shell date) > $(TARGETS): DATE := $(TGTDATE) > > at the slightly annoying price of calling the command once even if > making some target *not* in the TARGETS list. It is possible to avoid this price with ifeq ($(findstring aa,$(MAKECMDGOALS)),aa) dt:=$(shell set -x; date) endif regards, Dmitry
Re: simple assignment of target-specific variables
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 wrote: > On Tue, Jun 9, 2020 at 9:10 AM David Boyce 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 > >
Re: simple assignment of target-specific variables
On Tue, Jun 9, 2020 at 9:10 AM David Boyce 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
Re: simple assignment of target-specific variables
David Boyce (9 June 2020 15:10_ > I'm not saying this should be considered a bug but it's at least an > "interesting result". Indeed ! I presume the workaround is TGTDATE := $(shell date) $(TARGETS): DATE := $(TGTDATE) at the slightly annoying price of calling the command once even if making some target *not* in the TARGETS list. Eddy.
simple assignment of target-specific variables
I'm not saying this should be considered a bug but it's at least an "interesting result". I've always followed the rule of thumb that simple (:=) assignment should be used when the RHS contains $(shell ), and this is still a good mnemonic 99.9% of the time, but I've run across a case where it actually loses. Consider the following makefile: $ cat Makefile TARGETS := aa bb cc dd .PHONY: all all: $(TARGETS) $(TARGETS): at := $(shell set -x; date) $(TARGETS): @:$(info Making $@ at $(at)) when making only a subset of declared targets. With simple := assignment a shell is invoked for every target including those not being built: $ make bb + date + date + date + date Making bb at Fri Jun 5 08:12:25 PDT 2020 but with recursive = assignment only the required one is used: $ make bb + date Making bb at Fri Jun 5 08:12:36 PDT 2020 I understand why this happens but it does raise the question of how simple assignment should work in this case. Here's what the manual says: "The value of a simply expanded variable is scanned once and for all, expanding any references to other variables and functions, *when the variable is defined*." 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?
