Re: pattern rules and pattern-specific-variables problem

[Paul D. Smith]

%% Boris Kolpackov <address@hidden> writes:

  >> foo%bar : FOO = bar
  >> f%bar : BAR = baz
  >> 
  >> What would this rule print, and why...
  >> 
  >> fooZbar : ; @echo 'FOO = $(FOO)  /  BAR = $(BAR)'

  bk> I think it is reasonable to expect that it will print

  bk> FOO = bar
  bk> BAR = baz

  bk> The idea is quite simple. Right now make will "apply" all matching
  bk> pattern-specific variables in the order of definition. Proposed
  bk> change will apply them in a different order: from the most generic
  bk> to the most specialized.

Hm.  Unless we can pre-sort the patterns by, say, the length of the
pattern string _before_ expansion (in our example "foo%bar" is 7 chars,
which is longer than "f%bar" at 5 chars, so f%bar would be matched first
and foo%bar would be matched second) and have it always do the right
thing, there doesn't seem to be any efficient way to manage this.

Offhand I can't think of an instance where sorting by length would give
the wrong answer, but I haven't had my tea yet this morning :-).

  sh> It just seems more sensible that the best-match would win, as
  sh> opposed to 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.

  bk> We can leave the old behavior by default and allow makefile
  bk> writers to turn on the new behavior via MAKEFLAGS:

  bk> MAKEFLAGS += --enable-pattern-specialization

Yes... as you know, I just hate to add these kinds of flags to modify
basic behavior though: every extra option increases the potential
testing axes exponentially.

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <address@hidden>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist