"Paul D. Smith" <[EMAIL PROTECTED]> writes: > 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)'
Well, putting aside that this is a bit malformed, I think it is reasonable to expect that it will print FOO = bar BAR = baz The idea is quite simple. Right now make will "apply" all matching pattern-specific variables in the order of definition. Proposed change will apply them in a different order: from the most generic to the most specialized. This will result in the more specialized definitions overriding more generic ones: dbg/%.o: CFLAGS := -g %.o: CFLAGS := -O2 dbg/driver: dbg/driver.o driver: driver.o In current make, both dbg/driver.o and driver.o will end up with -O2 while the proposed algorithm will work as expected. > 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. We can leave the old behavior by default and allow makefile writers to turn on the new behavior via MAKEFLAGS: MAKEFLAGS += --enable-pattern-specialization -boris _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
