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 _______________________________________________ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32