make-w32
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: behavior on Win depends on whether \ or / is used??


From: Mark Galeck (CW)
Subject: RE: behavior on Win depends on whether \ or / is used??
Date: Sun, 13 Dec 2009 22:21:27 -0800

I am sorry Eli, please bear with me, but I don't at all understand what you are 
saying.  I read it several times and I still don't get it.  I understand your 
patch, that part I understand, the reason why I used "." is because that was 
the smallest SSCCE I could think of.  So let me show you a different SSCCE, 
that avoids the issue in the patch.  Also, I delete the last ";" as it is not 
needed and maybe caused some confusion.    

Here is the makefile, again, I only have foobar.s in foobar1 directory, not in 
foobar0, and there is no foobar.o (just so that the thing always builds).  

The makefile is:


SHELL=cmd.exe
                
vpath %.s ..\foobar0 ..\foobar1

%.o: %.s
                echo $<
                
..\foobar0\foobar.s:


Now, again, please excuse me if I repeat myself, from last time:

First.  The behavior with the above makefile, with the _backward_ slashes, is 
perfectly fine...  it does find the file foobar.s in directory foobar1, no 
matter the backslashes, it does echo what it's supposed to echo.  

So I don't understand why you are saying that make fails in this case, that it 
does not find in vpath what it should, ...  Nothing like that, it works 
perfectly fine.  


Now, second - when I change to forward slashes.  Here we have a failure:

echo ../foobar0/foobar.s


(last time, with "." it was a different failure, perhaps due to your patch not 
being there, so never mind that).

Why I call it a failure?  Well, you understand, that I don't just echo the 
prerequisite.  This is just in my SSCCE.  In reality, I attempt to do something 
with it, and when it comes time to do it, make dutifully exclaims that " cannot 
open file ../foobar0/foobar.s for reading" - well sure you can't - why did you 
think you found it???  It surely looks to me like make contradicting itself, 
no??


Here you are saying that this  behavior must be correct, because make thinks 
that there should be a file foobar0\foobar.s because I mention it.

  But no, the make manual specifically says, that if a target has a rule with 
no prerequisites and no commands (notice I omitted the ; this time, same 
failure occurs with or without the ;) then make will not complain if this file 
does not exist.  That is precisely why I have this rule, to prevent make 
complaining if that file were deleted.  So make should not complain about that 
file not existing.  And also, it should follow vpath and find that file in 
foobar1.  I don't understand why it's not doing that, with all forward slashes, 
while seems to be fine doing it with backward slashes.  


>Make looks up its
database of known files by literally comparing hash values of the file
names as strings, so foobar1/foobar.s and foobar1\foobar.s are not
considered equal, and the search fails.  This is your case.  

>There is a long comment in the function vpath.c:selective_vpath_search
which seems to describe why files mentioned as targets in the Makefile
are treated specially, but I don't understand what it says.  Perhaps
Paul or someone else could help in explaining the current behavior.

Mark:  Yes fine if that is so, if the rule such as 

../foobar0/foobar.s:  

somehow interferes with vpath directive,

then please don't have it as comments in that function, but please put it in 
the manual.  


Mark




reply via email to

[Prev in Thread] Current Thread [Next in Thread]