svn commit: r277803 - projects/clang360-import/lib/clang/include
Tijl Coosemans
tijl at FreeBSD.org
Wed Jan 28 19:24:34 UTC 2015
On Wed, 28 Jan 2015 13:39:46 -0500 Alexander Kabaev <kabaev at gmail.com> wrote:
> 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. :)
>
> 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.
FreeBSD doing things slightly differently than everybody else is often
also a cause of trouble for developers. In this case too. The fact
that FreeBSD didn't have /usr/lib/clang/$VERSION/include changed the
output of "cc -print-file-name=include" which is why there's an ugly
/usr/lib/include symlink. This link can be removed now.
That said, this commit breaks compiling with "cc -ffreestanding
-nostdinc -I`cc -print-file-name=include`" because clang versions of
std*.h headers aren't installed on FreeBSD which is yet another
thing that FreeBSD does differently. Maybe now is a good time to fix
that as well?
More information about the svn-src-projects
mailing list