[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug/feature regarding target filename resolution
From: |
Hua Yu |
Subject: |
Re: bug/feature regarding target filename resolution |
Date: |
Sat, 29 Jun 2002 12:15:34 -0400 |
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
>