%% Jens Schmidt <[EMAIL PROTECTED]> writes:
js> I cannot believe that this is a bug because it seems so basic.
js> And other makes behave identical. However, I didn't found a
js> single line of docu on that in the online-docu (I would have
js> expected it, or at least a link to it, in section "Using
js> Variables", subsection "References" or "Flavors".)
There is an explanation in "Using Variables" (at least) but you probably
didn't recognize because you're thinking about it incorrectly.
js> Maybe its just my strange way of thinking. I thought that if it
js> is the same for recursively expanded variables to write
js> FOO = $(BAZ)
js> BAZ = baz
js> or
js> BAZ = baz
js> FOO = $(BAZ)
js> then this would apply to the order of variable definition and
js> rule, too. Apparently, it does not. See below.
The order of definition of recursively expanded variables _doesn't_
matter.
Recursively expanded variables are not expanded until they're evaluated.
So, what _does_ matter is when the variable is _evaluated_.
The "Using Variables" page says this:
Variables and functions in all parts of a makefile are expanded when
read, except for the shell commands in rules, the right-hand sides of
variable definitions using `=', and the bodies of variable definitions
using the `define' directive.
So, in your makefile:
js> baz: $(FOO); @echo $(FOO):$^
js> FOO = foo
The $(FOO) reference in the prerequisite list doesn't meet any of the
criteria for the "except" clause, above, so it falls under the initial
clause: it's expanded when read.
When make reads that line, it hasn't yet read the next line, so the
value of FOO is empty. If you enable --warn-undefined-variables you
would see that you'd get a warning about this.
A more detailed explanation of expansion rules in make is available in
the ``How `make' Reads a Makefile'' section of the manual.
--
-------------------------------------------------------------------------------
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org http://www.paulandlesley.org/gmake/
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
_______________________________________________
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make