[PATCH] Fix Windows path formatting when using -MD

[Yaron Keren]

LLVM_ON_WIN32 is true for mingw and cygwin which always use gcc make.
For nmake vs make issue Driver::IsCLMode() could be used.


2015-04-11 2:46 GMT+03:00 Yung, Douglas <douglas_yung at playstation.sony.com>:

>  I got the same results as Sean. I guess the question now is if we want
> to support generating nmake compatible output, and if so, should we do it
> using a switch similar to how Intel has done it at the link Sean provided.
>
>
>
> Douglas Yung
>
>
>
> *From:* Sean Silva [mailto:chisophugis at gmail.com]
> *Sent:* Friday, April 10, 2015 16:32
> *To:* Robinson, Paul
> *Cc:* Yung, Douglas; llvm-commits at cs.uiuc.edu
>
> *Subject:* Re: [PATCH] Fix Windows path formatting when using -MD
>
>
>
>
>
>
>
> On Fri, Apr 10, 2015 at 11:13 AM, Robinson, Paul <
> Paul_Robinson at playstation.sony.com> wrote:
>
> Hi Sean,
>
> Were you trying that on Windows?  My understanding is that Microsoft's
> NMAKE wants quoted filespecs and will think backslashes are directory
> delimiters.
>
>
>
> I'm seeing:
>
>
>
> foo: bar\ baz
>
>
>
> NMAKE : fatal error U1073: don't know how to make 'bar\'
>
>
>
> foo: "bar baz"
>
>
>
> NMAKE : fatal error U1073: don't know how to make '"bar baz"'
>
>
>
> (but note that '"bar baz"' is actually satisfied by a file called `bar
> baz`; so nmake is not interpreting the quotes as part of the file name)
>
>
>
> I wasn't able to find a specific reference for the nmake syntax, but from
> these experiments, it is clear that nmake is incompatible and a gcc
> compatible driver that outputs nmake dependency files is broken. We
> obviously cannot change our gcc-compatible dependency files as that would
> break users (they may be using a unix make on windows).
>
>
>
> It appears that when Intel implemented dependency file generation in their
> Fortran compiler, they needed to have two different modes for make and
> nmake. See the last two posts in
> https://software.intel.com/en-us/forums/topic/269853
>
>
>
> -- Sean Silva
>
>
>
>  --paulr
>
>
>
> *From:* llvm-commits-bounces at cs.uiuc.edu [mailto:
> llvm-commits-bounces at cs.uiuc.edu] *On Behalf Of *Yung, Douglas
> *Sent:* Thursday, April 09, 2015 5:17 PM
> *To:* Sean Silva
> *Cc:* llvm-commits at cs.uiuc.edu
> *Subject:* RE: [PATCH] Fix Windows path formatting when using -MD
>
>
>
> Hi Sean, what you are saying does make sense, I'll talk with the team that
> owns the tool to see. Thanks!
>
>
>
> Douglas Yung
>
>
>
> *From:* Sean Silva [mailto:chisophugis at gmail.com <chisophugis at gmail.com>]
> *Sent:* Thursday, April 09, 2015 17:11
> *To:* Yung, Douglas
> *Cc:* llvm-commits at cs.uiuc.edu
> *Subject:* Re: [PATCH] Fix Windows path formatting when using -MD
>
>
>
> 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
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 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/20150411/5370f22d/attachment.html>