%% Tom Drabenstott <[EMAIL PROTECTED]> writes:
td> "As with automatic variables, these values are only available within the
td> context of a target's command script (and in other target-specific
td> assignments)."
td> Why are target-specific variables handled in this way? My desired
td> result is that the target-specific variable be used for _both_ the
td> prereq. section and the commands. Would it make sense for target
td> specific variables to behave in this way?
Why do they behave this way? I'm not sure I can give you a simple
answer to that. I'll give you a number of reasons of varying strengths
and we'll see what you think :)
First, because other makes that support target-specific variables,
although they do it with different syntax and call it different things
(conditional macros, etc.), behave this way.
Second, because it's technically challenging to do it the way you want;
consider this rule:
foo bar baz biz boz : $(BLAH)
In the behavior you suggest we have to re-evaluate the prerequisites
list 5 times, once for each target, just in case one of those targets
has a target-specific variable value that overrides BLAH.
Third, things like this couldn't be made to work, which means make's
behavior is annoying inconsistent. Currently it's annoying, but
consistent :). The prerequisite $(FOO) here _MUST_ evaluate to bar, not
baz:
FOO = bar
foo.x : FOO = baz
%.x: $(FOO)
...
Fourth, order becomes an issue for pattern-specific variables:
FOO = foo
%.x : FOO = bar
foo.x: $(FOO)
%.x : FOO = baz
Fifth, consistency with automatic variable behavior.
Anyway, these are a few reasons it behaves as it does.
--
-------------------------------------------------------------------------------
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
