svn commit: r277803 - projects/clang360-import/lib/clang/include

[Dimitry Andric]

On 28 Jan 2015, at 15:14, Alexander Kabaev <kabaev at gmail.com> wrote:
> 
> On Wed, 28 Jan 2015 08:42:48 +0100
> Dimitry Andric <dim at FreeBSD.org> wrote:
...
>> I'm not sure what the problem is with storing a compiler's
>> internal-only headers in the location where upstream expects them to
>> be?  Note that gcc does something similar; for example with the gcc49
>> port, it stores all its internal headers under:
>> 
>> /usr/local/lib/gcc49/gcc/i386-portbld-freebsd11.0/4.9.3/include
>> 
>> While I do agree that this is not a pretty-looking path, upstream has
>> chosen it to be like this, and there are most likely good reasons for
>> it.  As for clang, I just want to get rid of as many "FreeBSD is a
>> special snowflake" patches as I can.
> 
> Nobody _expects_ them to be there, for they are internal and not
> directly addressable by anyone. We can tweak locations as we see fit
> with no user visible consequences. What you destroy by this is the nice
> property we had to date - all of the base headers could be searched by
> simple grep on /usr/include and no obscure directories need to be
> remembered.

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?

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.

In other words, I consider this a win, not any form of loss. :)

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-projects/attachments/20150128/68d78c15/attachment.sig>