-include filename does not show correct dependency errors
When using the -include filename(instead of just include filename), if this filename includes dependencies that are missing, makefile does not show those missing dependencies... For example, if using: -include foo.d with foo.d being: foo.o: foo.c xxx.h Let's say xxx.h does not exist (and cannot be generated) , the make fails, but it does not say it's because of xxx.h missing. If instead, this is used: include foo.d then it works fine... I understand that the '-' in front of include means that THIS file 'foo.d' should not itself generate an error, but I would expect the content of foo.d to be used normally Looks like a bug to me. Btw, I am using make 3.81. -- View this message in context: http://www.nabble.com/-include-filename-does-not-show-correct-dependency-errors-tp21699973p21699973.html Sent from the Gnu - Make - Bugs mailing list archive at Nabble.com. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: -include filename does not show correct dependency errors
On Tue, Jan 27, 2009 at 8:59 PM, willard pie...@willard.com wrote: When using the -include filename(instead of just include filename), if this filename includes dependencies that are missing, makefile does not show those missing dependencies... For example, if using: -include foo.d with foo.d being: foo.o: foo.c xxx.h Let's say xxx.h does not exist (and cannot be generated) , the make fails, but it does not say it's because of xxx.h missing. Well, what _does_ it say? When I set up things to match your description, it mentions xxx.h for me: $ ls Makefile foo.cfoo.d $ cat Makefile all: foo -include foo.d $ cat foo.d foo.o: foo.c xxx.h $ make make: *** No rule to make target `xxx.h', needed by `foo.o'. Stop. $ make --version | head -1 GNU Make 3.81 Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: -include filename does not show correct dependency errors
this is my example (create the foo.d manually as below) $ cat bad.mak all: foo.d foo.ooo COMPILE=gcc %.o: %.c $(COMPILE) -c $ %.d: %.c $(COMPILE) -c $ -MM -o $*.d -include foo.d foo.ooo: foo.o ld -o foo.ooo foo.o [/cygdrive/d/opentv/tstmake] $ make -f bad.mak make: *** No rule to make target `foo.d', needed by `all'. Stop. [/cygdrive/d/opentv/tstmake] $ cat good.mak all: foo.d foo.ooo COMPILE=gcc %.o: %.c $(COMPILE) -c $ %.d: %.c $(COMPILE) -c $ -MM -o $*.d include foo.d foo.ooo: foo.o ld -o foo.ooo foo.o [/cygdrive/d/opentv/tstmake] $ make -f good.mak make: *** No rule to make target `xxx.h', needed by `foo.d'. Stop. [/cygdrive/d/opentv/tstmake] $ cat foo.d foo.d foo.o: foo.c xxx.h the only difference between the 'good.mak' and 'bad.mak' is the '-' prefix on the include... See that the good.mak really displays what the problem is... whereas the bad.mak messages are not helpful. -- View this message in context: http://www.nabble.com/-include-filename-does-not-show-correct-dependency-errors-tp21699973p21700324.html Sent from the Gnu - Make - Bugs mailing list archive at Nabble.com. ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make
Re: -include filename does not show correct dependency errors
On Tue, Jan 27, 2009 at 9:44 PM, willard pie...@willard.com wrote: this is my example (create the foo.d manually as below) Well, now that you've shown your whole Makefile, I have a guess as to why make is behaving as it is. It's tied that the face that you use foo.d both as an implicit target (by virtue of being an included makefile) and as an explicit target, as a dependency of 'all'. My guess is that when make first tries to build foo.d and fails, it marks foo.d as unbuildable, but not why. Later, when you have it try to build foo.d (again), it sees that it has already marked it as failed, so gives up directly. My advice is to avoid this by fixing your auto-dependency method. If you just build the *.d files concurrently with the *.o files, then you could avoid naming foo.d as either dependency or target. The details of why that works correctly and how to actually do that concurrent building can be found in the Advanced Auto-Dependencies section of http://make.paulandlesley.org/autodep.html Yeah, make should give a less misleading error message, but why spend time banging your head on a bug that could be avoided by making your own code less wasteful? Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make