Re: [PATCH 2/2] compare function

2020-06-09 Thread Edward Welbourne
Jouke Witteveen (8 June 2020 22:20) > This is an implementation of a $(compare) function as proposed by > Edward Welbourne. Yay ;^> Looks promising in general. As ever, review consists mostly of criticism, so let me just say I approve of the general plan, before I start in on that ... > It differ

Re: [PATCH 2/2] compare function

2020-06-09 Thread Jouke Witteveen
On Tue, Jun 9, 2020 at 10:53 AM Edward Welbourne wrote: > > Jouke Witteveen (8 June 2020 22:20) > > It differs from his original proposal in that it behaves differently > > when given 4 or 5 arguments. In short, it's signature is > > > > $(compare lhs,rhs,less-than[,greater-or-equal]) > > $(comp

Re: [PATCH 2/2] compare function

2020-06-09 Thread Edward Welbourne
On Tue, Jun 9, 2020 at 10:53 AM Edward Welbourne wrote: >> I note that your implementation only supports numeric lhs and rhs. >> Might it be worth falling back, if either of them isn't numeric, to >> doing a strcmp() comparison instead ? Possibly after stripping >> leading space from each. There

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 a

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 so

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

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 safe

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 pr

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 target

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 th