Thu 08 Mar 2007 01:38:07 PM UTC, comment #1:
I agree this is unpleasant; however I don't see anything make can do about it. Eval works by first expanding its argument(s), then evaluating the result. In your example, after the expansion of $(Y) make sees:
ifeq (1,1)
B := X\
endif
and there's no possible way that the eval can know that this backslash was originally contained in the variable A, rather than being written directly by you.
The only solution to this is for YOU to be more cautious about when you allow variables to expand. If you defer the expansion of A so that it's done by the eval itself instead of being done up front before eval is invoked, then you'll get the behavior you want; change the definition of Y as follows:
define Y
ifeq (1,1)
B := $$(A)
endif
endef
By using $$(A), it won't expand during the expansion of Y, and eval will see this:
ifeq (1,1)
B := $(A)
endif
with no backslash... THEN when eval evaluates this IT will expand A and set B to the right value (X\). For your "real life" example this would translate to:
define $(COMP)_CUSTOM_WX_TARGET
ifneq ($(filter bcb%,$(TOOLSET)),)
$(1): export PATH := $(BCCDIR)bin;$$(PATH)
endif
endef
Although, as a general rule, I find it best to defer expansion of ALL variables other than those that require it (typically as part of a call), so the above might be more safely written:
define $(COMP)_CUSTOM_WX_TARGET
ifneq ($$(filter bcb%,$$(TOOLSET)),)
$(1): export PATH := $$(BCCDIR)bin;$$(PATH)
endif
endef
I'm closing this for now but if anyone has any ideas on how to make this work better please add a note or bring it up on the mailing lists.
|