Re: shortest stem

Paul Smith <[email protected]>
Newsgroups gmane.comp.gnu.make.devel
Organization GNU's Not Unix!
Message-ID <[email protected]>
On Thu, 2009-09-24 at 09:49 +0200, Boris Kolpackov wrote:
> Hi Paul,
> 
> Paul D. Smith <[email protected]> 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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.