%% <[EMAIL PROTECTED]> writes:
lm> There is some weirdness going on with the append operator and
lm> target-specific contexts.
lm> The append operator should act immediately if the variable was
lm> originally assigned with an immediate assignment but this does not
lm> happen if the variable was globally assigned and the append is
lm> target-specific, the append does variable expansion (as if the
lm> variable had been deferred).
lm> VAR := $$LOGNAME
lm> bar: VAR += bar
lm> foo bar:
lm> echo $(VAR)
lm> colsw07m -> ~/src/make/make-3.81rc1/make bar
lm> echo OGNAME bar
lm> OGNAME bar
Hm. I agree that the results seem incorrect. Can you please file a bug
about this on the Savannah site?
However, I did spend some time looking at this and the fix is not that
simple. In fact, the behavior was changed precisely BECAUSE the
previous behavior, while it apparently handled this case, didn't work in
other cases.
The way make works today for appended target-specific variables is: when
the variable is expanded all the parts are put into a buffer, and then
the entire buffer is expanded within the context of the target's
variables etc.
After the first step, the static variable has worked and the buffer has:
$LOGNAME bar
in it. However, then that buffer is expanded in the second step and you
lose the "$L". By this time it's just a string and there's nothing to
say that one part shouldn't be expanded because it came from a simple
variable.
The obvious idea is to change it so that variables are expanded one at a
time, as they're added to the buffer, then not expand the string at the
end. In fact, this is how make used to do it and why it used to work.
However, this fails in situations like this:
FOO := foo
BAR = one $(FOO)
a: FOO := bar
a: BAR += two $(FOO)
a: ; @echo '$(BAR)'
Because of the recursive way make expands variables, if we evaluate the
global value of BAR (needed because of the += in the target-specific
value) when the value of FOO at that point is "foo" and you get output
of:
one foo two bar
instead of what you'd expect, which is:
one bar two bar
Fixing this is not that easy: basically we need to go back to expanding
variables as they're added, like we used to do it before, but instead of
expanding them within the context of their own variable set we have to
always expand them in the context of the file's variable set. And we
have to be sure we don't loop infinitely :-).
I can't guarantee whether this will be fixed in 3.81, given that time is
so short and the change is not trivial. We'll have to see. But please
do file a bug on this so it won't get lost.
Thanks!
--
-------------------------------------------------------------------------------
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make
