Re: pattern rules and pattern-specific-variables problem

[Greg Chicares]

On 2005-8-22 5:31 UTC, Paul D. Smith wrote:
> 
> 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)'
> 
> ??

Later discussions propose sorting as a way to detect the "best" match":

On 2005-8-24 4:03 UTC, Paul D. Smith wrote:
> %% Boris Kolpackov <address@hidden> writes:
>
>   bk> I believe you are right, pre-sorting pattern rules and
>   bk> pattern-specific variables to be longest-first should do the
>   bk> trick.
>
> Actually, we have to do them in opposite order.  That is, pattern rules
> need to be sorted with longest first, but pattern-specific variables
> need to be sorted shortest first, so that the most specific variables
> are set last and override the least specific ones.

In a case like

    fo%bar : FOO = bar
    foo%ar : BAR = baz
    fooZbar : @echo ;FOO = $(FOO)  /  BAR = $(BAR)

wouldn't 'determine best match by sorting on length' be indeterminate
here unless a stable sort algorithm is used? For instance, if qsort()
is used, C99 7.20.5.2/4 says
  If two elements compare as equal, their order in the
  resulting sorted array is unspecified.
Would a convention like 'resolve ties in favor of first occurrence'
or 'sort first by longest matching initial substring' be best here,
or would it be better to halt with a diagnostic message saying that
two rules are equally applicable?