Re: Variable definition in eval'd function

[Philip Guenther]

On Jan 3, 2008 5:01 AM, Bryan Ischo <address@hidden> wrote:
...
> First, let me apologize for some of the wording I used in my email.

Apology accepted.  Please accept mine for the snide remarks I included...


I'm half brain-fried from other stuff myself, so I'm just going to
respond to a couple general points and one specific one.  Taking them
out of order...

...
> Please note that the GNU Make manual does not describe the special
> behavior of variables in commands, at least as far as I can find.  The
> most appropriate section would seem to be "Basics of Variable References",
> which reads in part:
>
> "Variable references can be used in any context: targets, prerequisites,
> commands, most directives, and new variable values."
>
> But it doesn't say anything about how variable references in commands work
> differently than everywhere else.  If someone could point me to the part
> of the GNU Make manual that describes this behavior, I would really
> appreciate it!

You're missing section 3.9, "How `make' Reads a Makefile".  It's
explained there how the expansion of variables occurs immediately (as
the makefile is parsed) in some contexts and is deferred until the
involved text is used in other contexts and which contexts are which.


> Now as to your example above, you've thrown me a bit.  I tried the text in
> a makefile and it did not do what I expected.  I *thought* that $(call)
> just did text replacement of its argument variables into the template
> text.  But it seems that it also executes any function calls that it finds
> in the resulting text as well, and it does it recursively, until there are
> no more text functions, as the following example shows:

$(call) does nothing until the text it is in is subject to expansion.
The 'when' of that depends on where it is in the makefile (per the
info section I mentioned above).  When make does expand some text, it
expands it recursively such that all the text there has been expanded
exactly once.


...
> > If you want target-specific variables, then use target-specific variables!
> >
> > foo: VARIABLE = foo_variable
> > bar: VARIABLE = bar_variable
> > .PHONY: foo bar
> > foo bar:
> >         @echo $(VARIABLE)
>
> Yes, I did.  But they don't solve my problem as far as I can tell.  If you
> can use target-specific variables to somehow allow you to cause a variable
> referenced in a rule command to be evaluated when the rule is defined,
> instead of when the command is executed, please show me how.

Instead of performing variable expansion on the commands immediately,
how about saving the value(s) you want until when the commands _are_
subject to expansion?  That's what target-specific variables get you.
If foo.mk were to contain
---
foo: VARIABLE = foo_variable
---
then you could easily obtain the desired results with just one
$(eval).  Yes, that's a change to the 'specification', but:
1) it may just be an intermediate step to a solution that matches your
original spec,
2) perhaps it should be reexamined why foo.mk and bar.mk are separate
files instead
    of being one file with two lines...


Philip Guenther