make-alpha
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shortest stem


From: Paul Smith
Subject: Re: shortest stem
Date: Thu, 24 Sep 2009 12:25:45 -0400

On Thu, 2009-09-24 at 09:49 +0200, Boris Kolpackov wrote:
> Hi Paul,
> 
> Paul D. Smith <address@hidden> writes:
> 
> > > > For example, what about:
> > > > 
> > > >         %.o : %.c
> > > >         %-d.o : %.y
> >
> > 
> > Here's a thought.  What if we were even more picky, and ONLY re-ordered
> > rules where the prerequisites were also identical?
> 
> What about things like this:
> 
> %.o: %.c
> %-mt.o : %-mt.c

Oops.  Yeah.  Good point.  My idea won't work.

> Conceptually, I feel that pattern specificity should be the first
> criteria for picking rules (i.e., rules that match what you are
> trying to build more precisely are considered first). Prerequisites
> are the second criteria, not part of the first criteria.
> 
> > So, in my example above, it would work the same way as it does now
> > because the prerequisites were different.
> 
> Yes, but is it the right way? Why should '.c' prerequisite be preferred 
> to '.y'? On the other hand, I think it is clear that %-d.o should be
> preferred to %.o when we are building foo-d.o.

Well, this is exactly the feature that the current behavior allows: why
indeed is .c preferred to .y?  But at the same time, is it REALLY
_always_ the case that more specific is to be preferred, REGARDLESS of
the prerequisite list?  Maybe in this situation:

        %.o : %.y
        %.o : %.c
        %-m.o : %.x

we want the .o to be built from the .y, always, if it exists, even from
-m.c.  Or whatever.

The nice feature of the current behavior in make is that it is simple to
understand, completely flexible (you can get any behavior you want by
modifying the order), and 100% predictable.  Of course the downside is
that it might be difficult, in very complex makefile environments, to
get your rules to order the right way.  And, I guess, the behavior is
not what some people intuitively expect.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]