Re: bug/feature regarding target filename resolution

[Hua Yu]

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 <address@hidden>, "Paul 
>D
>. Smith" writes:
>>%% address@hidden 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
>