Re: simple assignment of target-specific variables

2020-06-28 Thread Dmitry Goncharov via Bug reports and discussion for GNU make
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

Re: simple assignment of target-specific variables

2020-06-09 Thread David Boyce
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

Re: simple assignment of target-specific variables

2020-06-09 Thread Dmitry Goncharov via Bug reports and discussion for GNU make
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

Re: simple assignment of target-specific variables

2020-06-09 Thread Dmitry Goncharov via Bug reports and discussion for GNU make
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

Re: simple assignment of target-specific variables

2020-06-09 Thread David Boyce
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

Re: simple assignment of target-specific variables

2020-06-09 Thread Dmitry Goncharov via Bug reports and discussion for GNU make
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:

Re: simple assignment of target-specific variables

2020-06-09 Thread Edward Welbourne
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

simple assignment of target-specific variables

2020-06-09 Thread David Boyce
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