[Top][All Lists]

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

Re: pattern rules and pattern-specific-variables problem

From: Shawn Halpenny
Subject: Re: pattern rules and pattern-specific-variables problem
Date: Mon, 15 Aug 2005 17:05:14 -0400

On 8/15/05, Boris Kolpackov <address@hidden> wrote:

> GNU make "gathers" variables in the order they appear in the makefile.
> In this case the second definition of patter-specific variable V
> overrides the first one.

> Shawn Halpenny <address@hidden> writes:
> > This is a serious problem for non-recursive make scenarios that make
> > extensive use of pattern rules for commands to build objects from
> > source in various subdirectories, because the pattern-specific
> > variable values that are used depend on the order of the rules.
> Agree. You can fix this in your particular case by rewriting the makefile
> like this:
> dir/%.o : V = dir/nondbg
> dir/dbg/%.o : V = dir/dbg
> dir/dbg/%.o : %.cpp | $$(V)/. dbg ; echo dbg-V:$(V); touch $@
> dir/%.o : %.cpp | $$(V)/. nondbg ; echo nondbg-V:$(V); touch $@
> In other words, you need to write the most specialized variable definitions
> last and the most specialized rules first.

Argh; that complicates things because I not only have to care what
order I include sub-makefiles in, but I have to care about the order
of pattern rules and pattern-rule-variables within them.

> Some time ago I proposed changing pattern rules selection algorithm from
> picking the first applicable rule to picking the most specialized one
> (formally, the one with the shortest stem). I guess this will also be
> useful (or even more so) for pattern-specific variables.

That would match how I originally thought they worked and would
certainly be least surprising and more deterministic than the current

I'm sure that change would break some makefiles out there, but I
wonder how many of them would continue to work the same way because
the people who wrote them were making the same assumption I was?

Shawn Halpenny

reply via email to

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