On 6/19/07, Agent Zhang <[EMAIL PROTECTED]> wrote:
...
I think the test case to demonstrate this bug can be simplified as:
define bogo
# $(warning this should not happen)
endef
all:
$(bogo)
And make produces
$ make -f a.mk
a.mk:5: this should not happen
#
Yeah, it's really funny.
Funny in the "this computer is broken: it only does what I tell it to,
not want I want!" sense, I presume. You told it to expand $(bogo)
completely, so it did. If you don't want that, then tell it to only
expand it one level, with $(value):
$ cat Makefile
define bogo
# $(warning this should not be evaluated here)
endef
all:
echo '$(value bogo)'
$ make
echo '# $(warning this should not be evaluated here)'
# $(warning this should not be evaluated here)
$
The trick is that you can't easily mix $(call) and $(value): there's
no way to say "give me the value of 'bogo', expanding *only* the
argument variables $(1), $(2), ... and not other variables or
functions in 'bogo's value". You have to indicate which variables
should have their expansion delayed *in the value of bogo*, by
doubling their '$':
$ cat Makefile
define bogo
# $$(warning this should not be evaluated here: $(1))
endef
all:
echo '$(call bogo,foo)'
$ make
echo '# $(warning this should not be evaluated here: foo)'
# $(warning this should not be evaluated here: foo)
$
If you were to say $(eval $(call bogo,foo)) in that file, you wouldn't
get a warning because the $(warning) wouldn't be expanded before the
eval, and in the eval it would be in a comment.
Also, $(info ...) and its families seem to evaluate "too early"
according to my vague impression.
Like all variables and functions, they are expanded when the context
they are in is expanded. Section 3.9 of the info pages describes
which contexts are subject to immediately expansion and which are
deferred until the containing variable is expanded or the rule's
commands are invokved.
Philip Guenther
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
