From owner-svn-src-projects@FreeBSD.ORG Wed Jan 28 18:39:50 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 DA12E253; Wed, 28 Jan 2015 18:39:49 +0000 (UTC) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (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 8C17AA47; Wed, 28 Jan 2015 18:39:49 +0000 (UTC) Received: by mail-qg0-f42.google.com with SMTP id q107so18013606qgd.1; Wed, 28 Jan 2015 10:39:48 -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=wkZycHOEhkSyPRA95+QGBDb4iVeJgkATbLQgtUbBeIY=; b=XRwdHZgKCIQr5ipictjADNdGDBoczw24gKv4iRT1xUkjJEyU45QS+MnB/X6EE/EliB 7tT0bCtV0NL4N1vppIC763Ut0HBxMyQB3zsmmnnsE1kl7s/r8l/txD+CSEUqJ4d6QT0a rIbNiv7ACoyZVEbcb2cfQIeU1T9ocgp3CkhO1LLkp55GVirvmu1yRFlhnsbDDPcn++8t 5GFJjW333amM2qq0tGmCKuGtTHYzaTdLLVJBLXW0MS7sJbUbIhw1TfQlMt/G6o5QvHgj x2zvnyrdOjeHGKHj8U2dAHC2jjSfpRiAwZ6/A9hN4CbLNVWzX6Zx6pjz9nW/okDpWBJs HWhg== X-Received: by 10.140.28.54 with SMTP id 51mr15291225qgy.6.1422470388434; Wed, 28 Jan 2015 10:39:48 -0800 (PST) Received: from kan ([2601:6:6780:7e0:226:18ff:fe00:232e]) by mx.google.com with ESMTPSA id e7sm4765053qag.10.2015.01.28.10.39.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jan 2015 10:39:47 -0800 (PST) Date: Wed, 28 Jan 2015 13:39:46 -0500 From: Alexander Kabaev To: Dimitry Andric Subject: Re: svn commit: r277803 - projects/clang360-import/lib/clang/include Message-ID: <20150128133946.7243a0fc@kan> In-Reply-To: <2DA71591-EE38-42F9-983F-8E711CA36A75@FreeBSD.org> References: <201501271925.t0RJPem3010417@svn.freebsd.org> <20150127191134.4fe3a17f@kan> <20150128091457.1b0ea3a7@kan> <2DA71591-EE38-42F9-983F-8E711CA36A75@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 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 18:39:50 -0000 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. -- Alexander Kabaev