From owner-svn-src-projects@FreeBSD.ORG Wed Jan 28 18:50:47 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 6311C6D7; Wed, 28 Jan 2015 18:50:47 +0000 (UTC) Received: from smtp6.ore.mailhop.org (smtp6.ore.mailhop.org [54.149.35.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40475BFB; Wed, 28 Jan 2015 18:50:47 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by smtp6.ore.mailhop.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1YGXhI-00014A-Pz; Wed, 28 Jan 2015 18:50:40 +0000 Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t0SIobPY026685; Wed, 28 Jan 2015 11:50:37 -0700 (MST) (envelope-from ian@freebsd.org) X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX19rXEMtNaHtm/smqB2CO1tR Message-ID: <1422471037.15718.64.camel@freebsd.org> Subject: Re: svn commit: r277803 - projects/clang360-import/lib/clang/include From: Ian Lepore To: Alexander Kabaev Date: Wed, 28 Jan 2015 11:50:37 -0700 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> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.8 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: Benjamin Kaduk , svn-src-projects@freebsd.org, "src-committers@freebsd.org" , Dimitry Andric 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 18:50:47 -0000 On Wed, 2015-01-28 at 13:39 -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. :) > > > > -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. > The change clearly improves maintainability, at essentially zero cost to usability, your contrived example notwithstanding. If the question were phrased "Hey, should we mix private header files belonging to the toolchain in with our public header files?" I would expect the answer to be an overwhelming "Hell no!" along with a variety of sarcastic comments about how the answer is really a no-brainer. -- Ian