[Top][All Lists]
[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