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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> <http://www.datasync.com/%7Esrivasta/> Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E