%% Boris Kolpackov <[EMAIL PROTECTED]> writes: >> foo%bar : FOO = bar >> f%bar : BAR = baz >> >> What would this rule print, and why... >> >> fooZbar : ; @echo 'FOO = $(FOO) / BAR = $(BAR)'
bk> I think it is reasonable to expect that it will print bk> FOO = bar bk> BAR = baz bk> The idea is quite simple. Right now make will "apply" all matching bk> pattern-specific variables in the order of definition. Proposed bk> change will apply them in a different order: from the most generic bk> to the most specialized. Hm. Unless we can pre-sort the patterns by, say, the length of the pattern string _before_ expansion (in our example "foo%bar" is 7 chars, which is longer than "f%bar" at 5 chars, so f%bar would be matched first and foo%bar would be matched second) and have it always do the right thing, there doesn't seem to be any efficient way to manage this. Offhand I can't think of an instance where sorting by length would give the wrong answer, but I haven't had my tea yet this morning :-). sh> It just seems more sensible that the best-match would win, as sh> opposed to 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. bk> We can leave the old behavior by default and allow makefile bk> writers to turn on the new behavior via MAKEFLAGS: bk> MAKEFLAGS += --enable-pattern-specialization Yes... as you know, I just hate to add these kinds of flags to modify basic behavior though: every extra option increases the potential testing axes exponentially. -- ------------------------------------------------------------------------------- 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
