================
Comment at: lib/Frontend/DependencyFile.cpp:298
@@ -295,3 +297,3 @@
for (unsigned i = 0, e = Filename.size(); i != e; ++i) {
- if (Filename[i] == ' ' || Filename[i] == '#')
+ if (Filename[i] == ' ' || Filename[i] == '#') {
OS << '\\';
----------------
probinson wrote:
> silvas wrote:
> > Why `#` also? We are trying to be gcc-compatible. See
> > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libcpp/mkdeps.c;h=78bbf09a0cc8c3ba0fe974b55e1ededf02c66665;hb=HEAD#l47
> No, we're trying to produce something that GNU Make can use. What gcc
> produces is broken by any definition.
>
> $ cat tspace.c
> #include "foo\ bar.h"
> #include "foo\#bar.h"
> int i;
> $ ls
> foo\ bar.h foo\#bar.h tspace.c
> $ gcc -c -MMD tspace.c
> $ cat tspace.d
> tspace.o: tspace.c foo\\\ bar.h foo\\#bar.h
> $ make -f tspace.d tspace.o
> make: *** No rule to make target `foo\', needed by `tspace.o'. Stop.
> $
>
Please file a bug with gcc.
Also, curiously that .d file seems to work for me on windows under cygwin:
```
Sean@Sean-PC ~
$ cat >tspace.c
#include "foo\ bar.h"
#include "foo\#bar.h"
int i;
Sean@Sean-PC ~
$ mkdir foo
Sean@Sean-PC ~
$ cd foo
Sean@Sean-PC ~/foo
$ mkdir ' bar.h'
Sean@Sean-PC ~/foo
$ mkdir '#bar.h'
Sean@Sean-PC ~/foo
$ cd ..
Sean@Sean-PC ~
$ cat >tspace.d
tspace.o: tspace.c foo\\\ bar.h foo\\#bar.h
Sean@Sean-PC ~
$ make -f tspace.d
cc -c -o tspace.o tspace.c
make: cc: Command not found
<builtin>: recipe for target 'tspace.o' failed
make: *** [tspace.o] Error 127
```
Also, clang's current output seems to work fine on cygwin. In what cases is
clang's output currently breaking? Is it just the case of filenames containing
backslashes followed by space/hash on unix?
The set of strings that can be correctly escaped in make is inherently limited,
so we are inherently compromising on what file names can be properly
represented. Does it make sense to extend the set of properly representable
filenames to files containing backslashes in their name?
E.g. include "foo\ bar.h". On unix we would be instructing make to look for a
file 'foo\ bar.h' in the current directory but on windows in my testing above
we would be instructing make to look for a file ' bar.h' in directory 'foo'.
Any project for which that would actually be correct behavior is insane. I
think that realistically, backslashes are only going to end up in includes on
windows where they will be intended as directory separators, and will result in
compilation errors on other platforms. I believe that clang's current output
actually works correctly in that case.
We might be overthinking this. What case are we fixing? And does it make sense
to fix that case?
http://reviews.llvm.org/D9208
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
