[PATCH] D37954: Expand absolute system header paths when using -MD depfiles

[Peter Wu via Phabricator via cfe-commits]

Lekensteyn added a comment.

In https://reviews.llvm.org/D37954#873384, @joerg wrote:

> ninja is not the only consumer of this. For human inspection, it can be quite surprising to see symlinks resolved, i.e. /usr/include/machine on NetBSD.


No problem, NetBSD disables this option by default:
https://github.com/IIJ-NetBSD/netbsd-src/blob/dd946191000153f9c8a927e5257e726879f48140/share/mk/bsd.sys.mk#L26
This option was added in https://github.com/IIJ-NetBSD/netbsd-src/commit/c7e9228e67fab47a6bbfb548117da93ebb20ff5c
(I am unable to find a (mailing list) discussion about the exact problem though.)

> Build systems have different ideas on whether they want absolute resolved paths or not, so it seems like ninja should be able to cope with either format. This is a lossy transformation, so I'm somewhat reluctant to agree with it.

Can you be specific about the build systems you have in mind? Note:

1. GCC has added and enabled this option by default in 2012 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52974). and
2. Ninja is currently slightly broken with Clang whereas it works fine with GCC.
3. To the best of my knowledge, there are no systems that break after this fix.

Looking at the GCC change, it also checks whether the canonicalized path is actually shorter. In that case the documented "shorten header paths" seems to make sense.

I thought it would be a good idea to make Clang compatible with GCC in this case, not sure what else could break.
If it turns out to be bad, it can be removed and/or worked around with the -fno-canonical-system-headers option.


https://reviews.llvm.org/D37954