On 8/15/05, Boris Kolpackov <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 algorithm. 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 _______________________________________________ Help-make mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-make
