From owner-svn-src-projects@FreeBSD.ORG Wed Jan 28 19:24:34 2015 Return-Path: Delivered-To: svn-src-projects@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8734D48A; Wed, 28 Jan 2015 19:24:34 +0000 (UTC) Received: from mailrelay106.isp.belgacom.be (mailrelay106.isp.belgacom.be [195.238.20.133]) by mx1.freebsd.org (Postfix) with ESMTP id 9DF5AF4F; Wed, 28 Jan 2015 19:24:33 +0000 (UTC) X-Belgacom-Dynamic: yes X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=Xz9Uco7AEzg9ElRFdtKQLJViOsXK4SGQVO9ewqrYxis= c=1 sm=2 a=kj9zAlcOel0A:10 a=pGLkceISAAAA:8 a=6I5d2MoRAAAA:8 a=Ytj25t-ICKyg-gAN8iIA:9 a=CjuIK1q_8ugA:10 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2CzBgDxNclU/xOHsFtagwaBK8pKAoEbRAEBAQEBfYQNAQU6HCMQCxgJJQ8SGB4GARIeh3oDFQHRGw2FLwEBAQEBAQEBAgEBAQEBARyNToIqB4QpAQSWUIFFgRiLNoI8gz0iggIcgVE9MYJCAQEB Received: from 19.135-176-91.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([91.176.135.19]) by relay.skynet.be with ESMTP; 28 Jan 2015 20:24:24 +0100 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.9/8.14.9) with ESMTP id t0SJONXu033333; Wed, 28 Jan 2015 20:24:23 +0100 (CET) (envelope-from tijl@FreeBSD.org) Date: Wed, 28 Jan 2015 20:24:22 +0100 From: Tijl Coosemans To: Alexander Kabaev , Dimitry Andric Subject: Re: svn commit: r277803 - projects/clang360-import/lib/clang/include Message-ID: <20150128202422.52016f68@kalimero.tijl.coosemans.org> In-Reply-To: <20150128133946.7243a0fc@kan> References: <201501271925.t0RJPem3010417@svn.freebsd.org> <20150127191134.4fe3a17f@kan> <20150128091457.1b0ea3a7@kan> <2DA71591-EE38-42F9-983F-8E711CA36A75@FreeBSD.org> <20150128133946.7243a0fc@kan> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Benjamin Kaduk , svn-src-projects@freebsd.org, "src-committers@freebsd.org" 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:24:34 -0000 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: >>>> >>>> /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 /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?