>From a brief look at depfile_parser.in.cc, it looks like Ninja does not correctly handle GCC's current behavior, and Paul's patch will actually make it "work". Clearly includes with `#` characters in them don't happen in practice.
Ninja's depfile_parser.cc tries to express the escaping rules as "backslash escapes certain characters", which is not the reality. Make's craziness is such that you cannot tell in isolation whether the backslashes in a substring `foo\\` need to be escaped or not without looking at the characters following that substring. -- Sean Silva On Fri, May 8, 2015 at 4:36 PM, Nico Weber <[email protected]> wrote: > On Fri, May 8, 2015 at 4:01 PM, Paul Robinson < > [email protected]> wrote: > >> In http://reviews.llvm.org/D9208#169446, @thakis wrote: >> >> > Does gcc intend to fix this soon? Isn't being compatible with gcc >> important >> > than the other things? >> >> >> If gcc emitted an incorrect relocation, would you argue that it's >> important to be compatible with gcc? Even if you could not point to any >> linker that handled that buggy relocation in a reasonable way? >> > > 'course not, but that's not the case here. If a program (say, ninja) tries > to be compatible with gnu make's depfile parsing, it would previously > convert "\ " to a space from what I understand. Now it's going to get "\\\ > " and think that that's "\ ". So this is breaking backwards compat of clang > with itself. >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
