BTW, the problem seems to be more pronounced with a complex makefile. > gmake "obj.sun4_solaris/JanusLib.a(../JanusLib/obj.sun4_solaris/codebook.o)" > > gmake "obj.sun4_solaris/JanusLib.a(codebook.o)" > gmake "obj.sun4_solaris/JanusLib.a(obj.sun4_solaris/codebook.o)" are all giving different results on Solaris (SunOS 5.5.1) with gmake 3.79.1.
Both ../JanusLib/obj.sun4_solaris/codebook.o) and obj.sun4_solaris/codebook.o points to the same file. Hua Hua Yu writes: > >In message <[EMAIL PROTECTED]>, "Paul >D >. Smith" writes: >>%% [EMAIL PROTECTED] writes: >> >> h> I'm not sure whether it's a bug or a feature. But it's annoying >> h> to me at the very least. Targets in a makefile are filenames, >> h> in most cases. >> >>They may be filenames in most cases, but make treats them as strings in >>virtually all cases. Make does simple string matching, not complex path >>matching. > >Well, I also noticed that gmake produces a different message in this case, >comparing to when it gets a non-existent target. If target names are strings, >the "No rule to make target ..." message is much clearer and easier for me >to debug the makefile. > >$ pwd >/home/hyu >$ cat Makefile >a.o: a.c > touch a.o >$ touch a.c >$ gmake ../hyu/a.o >gmake: Nothing to be done for `../hyu/a.o'. >$ gmake whatever >gmake: *** No rule to make target `whatever'. Stop. > >Hua > _______________________________________________ Bug-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-make
