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 <[EMAIL PROTECTED]> 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?
_______________________________________________
Help-make mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/help-make
