Re: shortest stem

[Boris Kolpackov]

Hi Paul,

Paul D. Smith <address@hidden> writes:

> I really hate having lots of flags and switches that change basic
> behavior.  More to understand, more to test, more to learn, etc.

I was thinking about a special target, but I agree in general.


> But, we need to make sure this change doesn't decrease the capability 
> of make in any important way before we turn it on.

I tested with the test suite (all pass) and my build system and didn't 
detect any regressions. I guess the release candidate will be a good
test for this logic, especially if we get it uploaded into some
distribution repository, e.g., Debian unstable, and wait for some
time to have it used to rebuild packages.


> I'm interested in your patch to implicit.c

The patch to implicit.c is rather small. It does two things: (1)
add struct tryrule which incorporates the rule itself, matches
count, and checked_lastslash flag. Before there were three parallel
arrays, tryrules, matches, and checked_lastslash but the last two
weren't allocated with the same number of elements (that's the bug).
Now they are all kept together. (2) Add stemlen to struct tryrule
and call qsort once tryrules has been populated.

Do you want me to commit it before your changes? Or I can adapt it 
to your changes, I am sure it won't be very difficult.



> I'd really appreciate it if folks with larger, more complex secondary 
> expansion environments would give it a whirl.

Sure, I have one of those.


> We do, actually: the GNU make manual is quite clear that patterns are
> processed in the order in which they appear in the makefile, and the
> first matching pattern (where the prerequisites either exist or can be
> built) is taken.

Ok, then we should probably make it optional.


> How does your patch manage for patterns that have different
> prerequisites? 

It doesn't care about prerequisites, only about the length of the 
stem. And it doesn't discard any rules, just the order in which
they will be tried.


> For example, what about:
> 
>       %.o : %.c
>       %-d.o : %.y
> 
> ? Today this ordering will always choose to build the .o from the .c
> file because it appears first.  After the change, how will this work?

For names which end on '-d.o' the second rule will be tried first. After
that, the usual logic applies.


> Similarly, what about multiple prereq patterns:
> 
>       %.o : %.a %.b
>       %.o : %.a
> 
> In today's make the first one will be chosen as long as %.b exists (or
> can be remade, but if it can be remade then the second will never be
> chosen), otherwise the second rule will be chose.

In this case the stem will be the same for both rules and they will
be tried in the definition order (actually, I just realized that qsort
is not stable, so I will need to fix that).

In general, I think the difference in behavior will be limited to
very small number of cases, namely, where there is more than one
pattern rule to build the same thing, and the rules differ in the
'specificity' of the target, e.g, '%.o' & '%-pic.o'. I don't think 
such situations are very common.

Boris