thakis added a comment.
I think for depfile generation, we generally try to be gcc-compatible (I can
link to prior changes in this spirit), so I think this seems like a good thing
to do to me. gcc only does this for system headers, yes?
Does gcc support the non-negated spelling of this flag
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:
joerg added a comment.
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. Build
systems have different ideas on whether they want absolute resolved paths or
not, so it seems like ninja should
Lekensteyn added a comment.
In https://reviews.llvm.org/D37954#873373, @joerg wrote:
> Resolving the path doesn't necessary shorten the string at all, in many cases
> it will be longer.
The description was based on the GCC manual page (" When preprocessing, do not
shorten system header paths
joerg added a comment.
The comments at the very least are misleading. Resolving the path doesn't
necessary shorten the string at all, in many cases it will be longer. I'm
really not sure if clang should resolve symlinks like this as it can be quite
surprising.
https://reviews.llvm.org/D37954
Hi Nico,
On Sun, Sep 17, 2017 at 10:47:24AM -0400, Nico Weber wrote:
> Have you checked how much the additional stat()ing added in this patch
> slows down builds?
Additional cost: zero :-)
The information is already collected by FileManager::getFile(), calling
tryGetRealPathName just reads
Have you checked how much the additional stat()ing added in this patch
slows down builds?
On Sep 16, 2017 11:49 PM, "Peter Wu via Phabricator via cfe-commits" <
cfe-commits@lists.llvm.org> wrote:
> Lekensteyn added a comment.
>
> I tried to contact Simon (the author of the GCC) patch with a
Lekensteyn added a comment.
I tried to contact Simon (the author of the GCC) patch with a question about
the -fno-canonical-system-headers, but his Google address is bouncing.
GCC has long survived with doing this by default, I wonder if this option could
just me omitted, enabling the feature
Lekensteyn created this revision.
Herald added a subscriber: klimek.
GCC defaults to expanding the dependencies in depfiles, resolving
components like ".." and symlinks. Mimic this feature to ensure that the
Ninja build tool detects the correct dependencies when a symlink changes
directory
