Re: Bug#27697: auto-include-dependency failure case
Hi,
To cut a long story short, you have some .c files that depend
on a .h file. Initially, that .h file does not depend on
anything. You have set it up so that the dependency files are created
for the .c files, and, sure enough, the dependency files are created
for the .c files when they do not exist.
Now, you change the .h files. The dependency files say that
the objects have to be remade (and they are). However, nothing says
that the .d files are to be remade whenever the .h files change.
Had the $(CC) -MM had been run, the dependencies would have
correctly been updated.
So it is not really that the .d files are incorrectly created,
the problem is that you are not advising make to recreate them
in all the cases that you should. Anything that would cause the .c
file to be recompiled should really be a cause to recompile the .d
file.
Since this is really pilot error, I am closing this bug.
Since this technique may be of interest to others, I am
forwarding this bug clsure report to debian-user (make wizardry seems
to be an lost art, alas). I am therefore enclosing the original bug
report.
The right way to do this, BTW, is to use the dependency rules
somewhat like this:
______________________________________________________________________
REASON = @if [ -f $@ ]; then \
echo "====== making $(notdir $@) because of $(notdir $?) ======";\
else \
echo "====== making (creating) $(notdir $@) ======"; \
fi
%.d: %.c
$(REASON)
-$(CC) ${DEPFLAGS} -M $(CPPFLAGS) $< | sed 's|$*\.o|& $@|' > $@
______________________________________________________________________
>>"Barak" == Barak Pearlmutter <bap@cs.unm.edu> writes:
Barak> (This bug should almost certainly be forwarded to the upstream
Barak> maintainers - I'm sending it here so the debian bug tracking system
Barak> will track it.)
Barak> Let's say you have a Makefile that uses the -MM mechanism discussed in
Barak> the make info file
>> Makefile
Barak> all: prog
Barak> sources=a.c b.c
Barak> OBJS=$(sources:.c=.o)
Barak> MAKS=$(sources:.c=.d)
Barak> include $(MAKS)
Barak> %.d: %.c
Barak> $(CC) -MM $(CPPFLAGS) $< > $@
Barak> prog: $(OBJS)
Barak> $(CC) -o $@ $(OBJS) -lm
Barak> and you have
Barak> /* a.c */
>> include "x.h"
Barak> int main(int argc, char **argv) { return 0; }
Barak> and
Barak> /* b.c */
>> include "x.h"
Barak> and
Barak> /* x.h */
Barak> /* #include "y.h" */
Barak> and now you make everything,
Barak> $ make
Barak> Makefile:8: a.d: No such file or directory
Barak> Makefile:8: b.d: No such file or directory
Barak> cc -MM b.c > b.d
Barak> cc -MM a.c > a.d
Barak> cc -c a.c -o a.o
Barak> cc -c b.c -o b.o
Barak> cc -o prog a.o b.o -lm
Barak> great, good deal. Now you edit x.h by uncommenting the #include,
Barak> /* x.h */
>> include "y.h"
Barak> and create y.h, say an empty file. Now you remake,
Barak> $ make -n
Barak> cc -c a.c -o a.o
Barak> cc -c b.c -o b.o
Barak> cc -o prog a.o b.o -lm
Barak> okay, great. Now you edit y.h
Barak> /* y.h */
Barak> /* i yam changed */
Barak> And NOW you remake:
Barak> $ make -n
Barak> make: Nothing to be done for `all'.
Barak> OOPS!!!! a.c and b.c both actually include y.h, via their inclusion
Barak> of x.h, so they should be remake. But a.d and b.d do not reflect
Barak> this. This is because they are old. Actually, a.d and b.d should
Barak> both be remade. There should have been dependencies "a.d b.d: x.h",
Barak> which would have solved the problem, as then the .d files would have
Barak> been remade. In fact, -MM could have added that dependency.
Barak> You might thing -MMD would add that dependency, since it's sure where
Barak> the output is going, and this bug could be fixed by just changing the
Barak> info file to advise the use of -MMD instead of -MM. Nope!
--
To any truly impartial person, it would be obvious that I am always
right.
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to: