Backslash quoting of targets and dependencies not described

[Robinson, Paul]

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