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

Alexander Kabaev kabaev at gmail.com
Wed Jan 28 18:39:50 UTC 2015


On Wed, 28 Jan 2015 16:37:44 +0100
Dimitry Andric <dim at FreeBSD.org> wrote:

> 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?
>

Because people do software development on FreeBSD from time to time
they tend to want to know what's in there. If one has to resolve to
start hunting for answers in header files, all they want is for you to
start hiding them in random places. grep -r <blah> /usr/include is easy.


> 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
> 

They are FreeBSD headers as long as you ship clang as part of FreeBSD
sources. Your change does not improve usability, since headers are
internal and having them under /usr/include does not hurt anyone nor is
that a change that is hard to maintain. By moving them you actively
hurt source transparency by forcing someone to potentially hunt for
answers in many disjoint directories and as such this is a net loss.
No smilies.

The choice is yours, of course.

-- 
Alexander Kabaev


More information about the svn-src-projects mailing list