From owner-svn-src-projects@FreeBSD.ORG Wed Jan 28 19:28:12 2015 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17F6AC2C; Wed, 28 Jan 2015 19:28:12 +0000 (UTC) Received: from tensor.andric.com (unknown [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 96B59FB7; Wed, 28 Jan 2015 19:28:11 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::7cc2:15cb:986d:f14e] (unknown [IPv6:2001:7b8:3a7:0:7cc2:15cb:986d:f14e]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 8BA5F5C2E; Wed, 28 Jan 2015 20:28:06 +0100 (CET) Subject: Re: svn commit: r277803 - projects/clang360-import/lib/clang/include Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_47735ED9-A882-42D9-8F59-1BE396B24FEC"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b4 (05244f0+) From: Dimitry Andric In-Reply-To: <20150128202422.52016f68@kalimero.tijl.coosemans.org> Date: Wed, 28 Jan 2015 20:28:06 +0100 Message-Id: <0129A21C-D178-49D9-9729-A94D30AACE48@FreeBSD.org> References: <201501271925.t0RJPem3010417@svn.freebsd.org> <20150127191134.4fe3a17f@kan> <20150128091457.1b0ea3a7@kan> <2DA71591-EE38-42F9-983F-8E711CA36A75@FreeBSD.org> <20150128133946.7243a0fc@kan> <20150128202422.52016f68@kalimero.tijl.coosemans.org> To: Tijl Coosemans X-Mailer: Apple Mail (2.2070.6) Cc: Benjamin Kaduk , svn-src-projects@freebsd.org, "src-committers@freebsd.org" , Alexander Kabaev X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jan 2015 19:28:12 -0000 --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 wrote: >=20 > On Wed, 28 Jan 2015 13:39:46 -0500 Alexander Kabaev = wrote: >> On Wed, 28 Jan 2015 16:37:44 +0100 >> Dimitry Andric wrote: >>> On 28 Jan 2015, at 15:14, Alexander Kabaev wrote: >>>> On Wed, 28 Jan 2015 08:42:48 +0100 >>>> Dimitry Andric 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 /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--