I'm not seeing any description of backslash-quoting special characters in target and dependency filespecs, in the GNU make manual located at www.gnu.org/software/make/manual/make.html.
It would be nice to get a description in the manual. Also by reply email, because I'm looking at fixing how Clang emits dependency files, which has backslash-related differences from GCC. For that matter, what GCC produces looks wrong as well, if you assume there's some rational rule about backslashes. That is, for this source: #include "x\y.h" #include "x\ z.h" Clang will produce this form: t.o: t.c x\y.h x\\ z.h that is, add a backslash in front of the space but not in front of the backslashes in the original; while GCC will produce this form: t.o: t.c x\y.h x\\\ z.h quoting the space and also doubling any backslashes immediately in front of the space, but not any other backslashes; and rationally what I'd expect to see is this form: t.o: t.c x\\y.h x\\\ z.h which is that any (backslash, space, '#') gets quoted with a backslash. I've observed that current GNU make accepts the third form, and does the right thing with it. As a fallback, it will also do the right thing with the second form, presumably to work around the peculiar GCC behavior of not backslash-quoting the "standalone" backslash. I'd prefer to have Clang emit the third form (which is actually the easy thing to do), however, some Clang people insist that it should produce exactly what GCC does "because we don't know" whether some tool or some version of GNU make actually depends on having the second form. There is commentary in the GCC source about the peculiarities of make's backslash-quoting requirements and "even GNU make 3.76.1 doesn't solve the problem entirely." Given that both the comment and the cited make version are about 15 years old, I suspect "the problem" has been long solved and the GCC tactic is totally unnecessary. So, if you could tell me when GNU make started accepting the third form, I can probably persuade the Clang people that we should be emitting that instead of the bug-for-bug GCC compatible second form. Thanks, --paulr _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
