Re: $(if-eq ...)

[Philip Guenther]

On 6/29/07, Stephan Beal <address@hidden> wrote:
> On Saturday 30 June 2007, Philip Guenther wrote:
> > The closest alternative I can think of is to instead pass the names
> > of variables to be evaluated for the 'then' and 'else' clauses:
> >
> > mythen = $(warning this should happen)
> > myelse = $(warning this should not happen)
> > $(call if-eq-vars,abc,abc,mythen,myelse)
>
> i thought about that, but the general problem is that i don't ALWAYS
> want to $(eval) the result. Sometimes i want to use it as-is. e.g., a
> rather contrived example would be the equivalent of:
>
> $(if abc,$(eval ...),$(error ...))

Hmm, good point.  That's still doable in the "then and else stuff in
variables" method, however:

if-eq-vars = $(if $(findstring $1,$2),$(if $(findstring
$2,$1),${$3},${$4}),${$4})

(if $1 is a substring of $2, and $2 a substring of $1, then $1 == $2...)



mythen = $(warning this should happen)
myelse = blip $@
foo = $(call if-eq-vars,abc,abc,mythen,myelse)
bar = $(call if-eq-vars,abc,def,mythen,myelse)


all:
       @echo foo = ${foo}
       @echo bar = ${bar}

$ gmake
Makefile:35: this should happen
foo =
bar = blip all
$


> > ...but it's clunky to use, eliminating most the point of the
> > function.
>
> i agree.

For stuff where the 'then' and 'else' clauses don't have any
side-effects, you can just use:

if-eq = $(if $(findstring $1,$2),$(if $(findstring $2,$1),$3,$4),$4)


(Functional programming advocates would argue that the side-effects
are the problem, not the lack of unexpanded arguments...)


> Oh, well.
>
> Maybe we can get an $(if-eq LHS,RHS,THEN[,ELSE]) in 3.82? :) :) :)

I thought portability to 3.80 was a concern.


Philip Guenther