[PATCH] Fix Windows path formatting when using -MD

[Sean Silva]

Actually, looking at this, I think that the root cause of your problem is
that your tool is not interpreting the makefile properly. This patch will
break every program that properly reads makefiles. Please verify that your
tool interprets the attached file "Makefile" as a file "foo" depending on a
file "bar baz". This is the output of BSD make and GNU make:

Sean:~/tmp/testmake % make
make: *** No rule to make target `bar baz', needed by `foo'.  Stop.
zsh: exit 2     make
Sean:~/tmp/testmake % gnumake
gnumake: *** No rule to make target `bar baz', needed by `foo'.  Stop.
zsh: exit 2     gnumake

If instead of bar\ baz I write "bar baz" (see attached file "broken"), as
your patch causes us to do, then this is the output:

Sean:~/tmp/testmake % make -f broken
make: *** No rule to make target `"bar', needed by `foo'.  Stop.
zsh: exit 2     make -f broken
Sean:~/tmp/testmake % gnumake -f broken
gnumake: *** No rule to make target `"bar', needed by `foo'.  Stop.
zsh: exit 2     gnumake -f broken

Please verify that your tool inteprets the makefile in this way. i.e. `"bar
baz"` is actually two files `"bar` and `baz"`.

-- Sean Silva

On Thu, Apr 9, 2015 at 4:55 PM, Sean Silva <chisophugis at gmail.com> wrote:

>
>
> On Thu, Apr 9, 2015 at 3:33 PM, Yung, Douglas <
> douglas_yung at playstation.sony.com> wrote:
>
>>  Hi Sean,
>>
>>
>>
>> The program we are using that consumes the compiler’s –MD output is a
>> tool that we produce which parses the output to provide integration with
>> Visual Studio.
>>
>>
>>
>> I agree that the example you gave of OpenFile(“\”foo.txt\””) would not be
>> valid, although I’m not sure that the compiler would even generate that on
>> Windows. According to the MSDN documentation (
>> https://msdn.microsoft.com/en-us/library/aa365247), a double quote is
>> not a valid character for a filename, so the compiler should never even
>> reach this point in the code because the compiler would have been unable to
>> resolve the reference to begin with.
>>
>
>
> No, I mean that any tool that actually reads the makefiles produced by
> this patch would end up with paths like "\"foo.txt\"". That your tool is
> interpreting the output of this patch the way you want indicates that it is
> not actually correctly parsing the makefile syntax.
>
> E.g. a makefile like this:
>
> foo.o: "C:\Program Files\bar.h"
>
> actually means that "foo.o" depends on "\"C:\Program Files\bar.h\"". If
> your tool does not interpret it like this, then your tool is not
> interpreting the makefile correctly.
>
> -- Sean Silva
>
>
>>
>>
>> Douglas Yung
>>
>>
>>
>> *From:* Sean Silva [mailto:chisophugis at gmail.com]
>> *Sent:* Thursday, April 09, 2015 14:57
>> *To:* Yung, Douglas
>> *Cc:* llvm-commits at cs.uiuc.edu
>> *Subject:* Re: [PATCH] Fix Windows path formatting when using -MD
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Apr 9, 2015 at 12:27 PM, Yung, Douglas <
>> douglas_yung at playstation.sony.com> wrote:
>>
>> Hi,
>>
>>
>>
>> This patch fixes a problem on Windows when the compiler generates a
>> dependency file using –MD or –MMD. The problem is that when emitting a path
>> that contains spaces, the compiler emits it by escaping the spaces with a
>> leading backspace character which is not valid in Windows. The proper fix
>> for this is to just emit the path enclosed in double quotes which is
>> accepted by Windows. This patch makes that change, and the compiler will
>> then generate the double quoted paths only when the compiler is hosted on
>> Windows. It also updates 3 tests that were affected by this change to
>> accept this change on Windows as well as verify the change works as
>> expected.
>>
>>
>>
>> What program are you using that consumes makefiles and interprets quoted
>> strings? Quoted strings are not part of Makefile syntax. This will result
>> in programs making calls like OpenFile("\"foo.txt\"") which I don't think
>> is valid.
>>
>>
>>
>> -- Sean Silva
>>
>>
>>
>>
>>
>> Douglas Yung
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150409/376719a4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 23 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150409/376719a4/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: broken
Type: application/octet-stream
Size: 24 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150409/376719a4/attachment-0001.obj>