%% Shawn Halpenny <[EMAIL PROTECTED]> writes:
sh> Yeah, I should have caught that. Nonetheless, pattern-specific
sh> variable definitions not necessarily matching up as expected with
sh> their associated rules+commands was definitely surprising.
Pattern-specific variable definitions, perhaps unfortunately, don't use
at all the same model as pattern rules. That's because make must choose
exactly one rule for each target, but you can have as many different
pattern-specific variable definitions as you like. Obviously if you try
to redefine the same variable more than once (without += or similar)
only one of them will take effect.
So (at least in the latest versions of make), _all_ matching
pattern-specific variable definitions will apply.
I understand that since all of them apply and make doesn't stop at the
first one, like it does for actual pattern rules, it seems a little
backwards.
I can't think of any good solution to that.
Even if we were to change pattern rules to work with a "best match"
algorithm, pattern-specific variable definitions can't work like that;
again, you're not choosing ONE pattern-specific variable definition.
What if I have:
foo%bar : FOO = bar
f%bar : BAR = baz
What would this rule print, and why...
fooZbar : ; @echo ;FOO = $(FOO) / BAR = $(BAR)'
??
sh> I would definitely argue about "equally applicable". It just
sh> seems more sensible that the best-match would win, as opposed to
sh> the first match.
Possibly. But GNU make has had the current behavior for 15+ years now.
I'm not willing to change that behavior lightly.
--
-------------------------------------------------------------------------------
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
_______________________________________________
Help-make mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/help-make
