[Top][All Lists]

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

Re: [bug #17880] Manual needs example for order-only prerequisites

From: Philip Guenther
Subject: Re: [bug #17880] Manual needs example for order-only prerequisites
Date: Thu, 28 Sep 2006 18:47:10 -0600

On 9/28/06, Sam Ravnborg <address@hidden> wrote:
Last time this was requested there was noone that could cook up
a sensible example for this strange feature.
So unless you come up with a good proposal it may not happen.

Finding a sensible example is easy: use it to require that generated
.h files (such as from lex or yacc) are built before files that
_might_ include them are compiled.  But that only makes real sense if
you're using automatic dependency generation: if not, then you're
either missing dependencies or having to hardcode them...in which case
what does the order-only prerequisite get you?

So, putting together the automatic-dependency generation code from
section 4.14 with a simple program using yacc, we get:

OBJS = main.o lexer.o y.tab.o

program: $(OBJS)
       $(LINK.c) -o $@ $(OBJS)

y.tab.c y.tab.h: parser.y
       $(YACC.y)  $@

# Without this line, make could chose to compile lexer.o before
running yacc, which
# will fail if lexer.c includes y.tab.h.  If the '|' was removed,
making this a normal
# dependency, then changing the parser.y file would result in more files being
# recompiled than necessary.
$(OBJS): | y.tab.h

# auto-dependency generation
%.d: %.c
       @set -e; rm -f $@; \
       $(CC) -M $(CPPFLAGS) $< > address@hidden; \
       sed 's,\($*\)\.o[ :]*,\1.o $@ : ,g' < address@hidden > $@; \
       rm -f address@hidden

# Generating the dependencies needs the y.tab.h file too
$(OBJS:.o=.d): | y.tab.h

# pull in the dependencies
include $(OBJS:.o=.d)

Looks good...until you realize that the order-only dependency of the
the objects on the y.tab.h file isn't actually needed!  The dependency
generation is guaranteed to build it first.  So the example works, but
is misleading.  Removing the unnecessary dependency
looks...strange...and you'll want to put it back when you switch to
'advanced' dependency generation, where the .d files are built as you
build the .o files.

Is this example better than nothing?  Got me...

Philip Guenther

reply via email to

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