Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Jan 2015 20:28:06 +0100
From:      Dimitry Andric <dim@FreeBSD.org>
To:        Tijl Coosemans <tijl@freebsd.org>
Cc:        Benjamin Kaduk <bjkfbsd@gmail.com>, svn-src-projects@freebsd.org, "src-committers@freebsd.org" <src-committers@freebsd.org>, Alexander Kabaev <kabaev@gmail.com>
Subject:   Re: svn commit: r277803 - projects/clang360-import/lib/clang/include
Message-ID:  <0129A21C-D178-49D9-9729-A94D30AACE48@FreeBSD.org>
In-Reply-To: <20150128202422.52016f68@kalimero.tijl.coosemans.org>
References:  <201501271925.t0RJPem3010417@svn.freebsd.org> <CAJ5_RoAvww7xFsSTBMPDThYsbpVbxOs11nWE=eEXpJRFx_kyww@mail.gmail.com> <20150127191134.4fe3a17f@kan> <F7477A20-BC56-4CF9-8520-77F7BFD4B72E@FreeBSD.org> <20150128091457.1b0ea3a7@kan> <2DA71591-EE38-42F9-983F-8E711CA36A75@FreeBSD.org> <20150128133946.7243a0fc@kan> <20150128202422.52016f68@kalimero.tijl.coosemans.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--Apple-Mail=_47735ED9-A882-42D9-8F59-1BE396B24FEC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On 28 Jan 2015, at 20:24, Tijl Coosemans <tijl@freebsd.org> wrote:
>=20
> On Wed, 28 Jan 2015 13:39:46 -0500 Alexander Kabaev <kabaev@gmail.com> =
wrote:
>> On Wed, 28 Jan 2015 16:37:44 +0100
>> Dimitry Andric <dim@FreeBSD.org> wrote:
>>> On 28 Jan 2015, at 15:14, Alexander Kabaev <kabaev@gmail.com> wrote:
>>>> On Wed, 28 Jan 2015 08:42:48 +0100
>>>> Dimitry Andric <dim@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:
>>>>>=20
>>>>> /usr/local/lib/gcc49/gcc/i386-portbld-freebsd11.0/4.9.3/include
>>>>>=20
>>>>> 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.
>>>>=20
>>>> 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.
>>>=20
>>> 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?
>>=20
>> 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.
>>=20
>>> 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.
>>>=20
>>> In other words, I consider this a win, not any form of loss. :)
>>=20
>> 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.
>=20
> 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=3Dinclude" which is why there's an ugly
> /usr/lib/include symlink.  This link can be removed now.
>=20
> That said, this commit breaks compiling with "cc -ffreestanding
> -nostdinc -I`cc -print-file-name=3Dinclude`" 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?

We never installed any internal clang headers that were named the same
as our own headers, because they used to cause conflicts.  I will have
a look if those conflicts have now been resolved, then we could install
them for use in freestanding environments.

-Dimitry


--Apple-Mail=_47735ED9-A882-42D9-8F59-1BE396B24FEC
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.26

iEYEARECAAYFAlTJOEYACgkQsF6jCi4glqO+9QCfQiTQpYbmpA8uYD/EvqLFdrmI
UusAnAtLINbTGQgOVD+UcRu7LvIszMrj
=kU/g
-----END PGP SIGNATURE-----

--Apple-Mail=_47735ED9-A882-42D9-8F59-1BE396B24FEC--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0129A21C-D178-49D9-9729-A94D30AACE48>