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

[Alexander Kabaev]

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.

-- 
Alexander Kabaev