Date: Wed, 28 Jan 2015 15:49:49 +0000 From: David Chisnall <theraven@FreeBSD.org> To: Dimitry Andric <dim@FreeBSD.org> Cc: Benjamin Kaduk <bjkfbsd@gmail.com>, svn-src-projects@freebsd.org, "src-committers@freebsd.org" <src-committers@freebsd.org>, Alexander Kabaev <kabaev@gmail.com> Subject: Re: svn commit: r277803 - projects/clang360-import/lib/clang/include Message-ID: <CD12FDA6-4ED4-43AE-8C77-2D8AC8C03BD0@FreeBSD.org> In-Reply-To: <2DA71591-EE38-42F9-983F-8E711CA36A75@FreeBSD.org> References: <201501271925.t0RJPem3010417@svn.freebsd.org> <CAJ5_RoAvww7xFsSTBMPDThYsbpVbxOs11nWE=eEXpJRFx_kyww@mail.gmail.com> <20150127191134.4fe3a17f@kan> <F7477A20-BC56-4CF9-8520-77F7BFD4B72E@FreeBSD.org> <20150128091457.1b0ea3a7@kan> <2DA71591-EE38-42F9-983F-8E711CA36A75@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28 Jan 2015, at 15:37, Dimitry Andric <dim@FreeBSD.org> wrote: >=20 > First you say "they are internal and not directly addressable", and in > the next sentence you say that it is a "nice property that you could > search by grepping /usr/include". If the files are internal and not > directly addressable, why would you ever want to search them? >=20 > In that respect, it is even better to relocate them to a different > location than /usr/include, since they're not *FreeBSD* headers, = they're > clang internal headers. >=20 > In other words, I consider this a win, not any form of loss. :) It's also worth noting that these headers are likely to go away at some = point. The fact that the clang libraries look for them in a = clang-binary-relative location is already problematic for libTooling = consumers, so they are likely to become internal resources in one of the = libClang* libraries. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CD12FDA6-4ED4-43AE-8C77-2D8AC8C03BD0>