[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pattern rules and pattern-specific-variables problem

From: Boris Kolpackov
Subject: Re: pattern rules and pattern-specific-variables problem
Date: Mon, 22 Aug 2005 08:12:45 +0000 (UTC)
User-agent: nn/6.6.5+RFC1522

"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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]