Re: pattern rules and pattern-specific-variables problem

[Boris Kolpackov]

"Paul D. Smith" <address@hidden> 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