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

[Bryan Drewery]

On 1/28/2015 8:14 AM, Alexander Kabaev wrote:
> On Wed, 28 Jan 2015 08:42:48 +0100
> Dimitry Andric <dim at FreeBSD.org> wrote:
> 
>> On 28 Jan 2015, at 01:11, Alexander Kabaev <kabaev at gmail.com> wrote:
>> On Tue, 27 Jan 2015 14:34:21 -0500
>>>
>>> Benjamin Kaduk <bjkfbsd at gmail.com> wrote:
>>>
>>>> On Tue, Jan 27, 2015 at 2:25 PM, Dimitry Andric <dim at freebsd.org>
>>>> wrote:
>>>>
>>>>> Author: dim
>>>>> Date: Tue Jan 27 19:25:39 2015
>>>>> New Revision: 277803
>>>>> URL: https://svnweb.freebsd.org/changeset/base/277803
>>>>>
>>>>> Log:
>>>>>  Change the path to clang's private headers.  Upstream has always
>>>>> stored these in $LIBDIR/clang/$VERSION/include, instead of our
>>>>> previous custom location in /usr/include/clang/$VERSION.  This
>>>>> allows us to drop yet another FreeBSD-specific patch.
>>>>>
>>>>> Modified:
>>>>>  projects/clang360-import/lib/clang/include/Makefile
>>>>>
>>>>> Modified: projects/clang360-import/lib/clang/include/Makefile
>>>>>
>>>
>>> I think spreading .h files all over the tree is actually a
>>> regression.
>>
>> 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.
>>
>> -Dimitry
>>
> 
> 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. Also note that ports can do whatever they want as long they
> do not stomp on the word, my concern is about base only.
> 

I've often grepped internal headers in /usr/include to try to understand
some compiler errors better. This was mostly with C++ template errors.

I did not know GCC was storing headers in /usr/lib/.../include. Having
to include /usr/lib/.../include is a little annoying, but it is even
more annoying to have FreeBSD be different than other platforms,
assuming those other systems are adopting the upstream location as well.

-- 
Regards,
Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-src-projects/attachments/20150128/f0eefe78/attachment.sig>