From owner-svn-src-projects@FreeBSD.ORG Fri Jan 30 01:43:38 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 4AB0BC17; Fri, 30 Jan 2015 01:43:38 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF9149FD; Fri, 30 Jan 2015 01:43:37 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id w8so18054378qac.13; Thu, 29 Jan 2015 17:43:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=lMOCWwXrXIMgusObA2n66lfH4chLTo/z8Qqhs/XRlpc=; b=tkbQ0wxezB7bj7VsKd+o8VbkEC2Kf4YyEzqI7dgIDaLEhLly4LdHCwQCI/O3NaM7yJ TfBCf5OBEtiC0b4hxSVbluCQGHRu5wUOH659SrMGOG2ikomznmR/17IhW01gtQhwsDKC jEdIc6Fe0SeqwruqRzpHyzb7pg8rh9Y7a6su8lrTpMki6L1e5dGwWSlKCWIP3cCdtwng NVe9qyflX/6V+nf5pZ6DvUUfGGNs9tsPPEQcHJUxjHBxjsAkLeBLlXOYKhUZGVj6CBT1 tSgFBim/Npe7a7kL0WSeB0ECrOIQdNnntXyGBPVUw+hAIkU625t6FSUXEYlVm5HnsPsw 3RPg== X-Received: by 10.229.249.137 with SMTP id mk9mr7789769qcb.4.1422582217130; Thu, 29 Jan 2015 17:43:37 -0800 (PST) Received: from kan ([2601:6:6780:7e0:226:18ff:fe00:232e]) by mx.google.com with ESMTPSA id m74sm8681302qgd.17.2015.01.29.17.43.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jan 2015 17:43:36 -0800 (PST) Date: Thu, 29 Jan 2015 20:43:35 -0500 From: Alexander Kabaev To: Ian Lepore Subject: Re: svn commit: r277803 - projects/clang360-import/lib/clang/include Message-ID: <20150129204335.43ed88f1@kan> In-Reply-To: <1422471037.15718.64.camel@freebsd.org> References: <201501271925.t0RJPem3010417@svn.freebsd.org> <20150127191134.4fe3a17f@kan> <20150128091457.1b0ea3a7@kan> <2DA71591-EE38-42F9-983F-8E711CA36A75@FreeBSD.org> <20150128133946.7243a0fc@kan> <1422471037.15718.64.camel@freebsd.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 30 Jan 2015 03:17:03 +0000 Cc: Benjamin Kaduk , Dimitry Andric , src-committers@freebsd.org" , svn-src-projects@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: Fri, 30 Jan 2015 01:43:38 -0000 On Wed, 28 Jan 2015 11:50:37 -0700 Ian Lepore wrote: > 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 > I presume that is why we did the other day around ever since forever. 'Hell no' indeed. -- Alexander Kabaev -- Alexander Kabaev