From owner-svn-src-projects@FreeBSD.ORG Wed Jan 28 14:15:01 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 C688AC72; Wed, 28 Jan 2015 14:15:01 +0000 (UTC) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (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 7A335982; Wed, 28 Jan 2015 14:15:01 +0000 (UTC) Received: by mail-qg0-f49.google.com with SMTP id i50so16751643qgf.8; Wed, 28 Jan 2015 06:15:00 -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=I/zcOPLrZuMvsjbQ7D3fDMGUgOCCIIn0XwpTJPVtWAs=; b=h9/7xbqtbqIfH2U76YgghKpyItHEQah+KxdQrgZgQzrSGx+Zf9wnMe6uhjASIo+1Sh l9uvYSmoLLz3g2eiUqlwx3Zaq3ab6p3dd675rRZfIbl3KYvReMum1YCAe+GdmRmZQJBJ pcmxQ5ZSqcsHH7sI5iWUFz//pAzB8zuqDd52jJFRv9VxxTySTvVw9YikOf/vJVIyghXd ahLZmaqeLRW8FyklyBtXCsnBiDRv08sdtAKUFs4koJ5+AqUoHJ8xnPBn6PL09EjLx+hn jfA0r9EuLLJxnVqVjjkoG8tUVZzu+kqNBuKYV8fOymKsLGzBaTQFmSBBkY0qXnZ/tcyB Omrw== X-Received: by 10.224.111.194 with SMTP id t2mr12990611qap.86.1422454500566; Wed, 28 Jan 2015 06:15:00 -0800 (PST) Received: from kan ([2601:6:6780:7e0:226:18ff:fe00:232e]) by mx.google.com with ESMTPSA id e9sm4113599qgd.18.2015.01.28.06.14.59 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jan 2015 06:14:59 -0800 (PST) Date: Wed, 28 Jan 2015 09:14:57 -0500 From: Alexander Kabaev To: Dimitry Andric Subject: Re: svn commit: r277803 - projects/clang360-import/lib/clang/include Message-ID: <20150128091457.1b0ea3a7@kan> In-Reply-To: References: <201501271925.t0RJPem3010417@svn.freebsd.org> <20150127191134.4fe3a17f@kan> 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 14:15:02 -0000 On Wed, 28 Jan 2015 08:42:48 +0100 Dimitry Andric wrote: > On 28 Jan 2015, at 01:11, Alexander Kabaev wrote: > On Tue, 27 Jan 2015 14:34:21 -0500 > > > > Benjamin Kaduk wrote: > > > >> On Tue, Jan 27, 2015 at 2:25 PM, Dimitry Andric > >> wrote: > >> > >>> Author: dim > >>> Date: Tue Jan 27 19:25:39 2015 > >>> New Revision: 277803 > >>> URL: https://svnweb.freebsd.org/changeset/base/277803 > >>> > >>> Log: > >>> Change the path to clang's private headers. Upstream has always > >>> stored these in $LIBDIR/clang/$VERSION/include, instead of our > >>> previous custom location in /usr/include/clang/$VERSION. This > >>> allows us to drop yet another FreeBSD-specific patch. > >>> > >>> Modified: > >>> projects/clang360-import/lib/clang/include/Makefile > >>> > >>> Modified: projects/clang360-import/lib/clang/include/Makefile > >>> > > > > I think spreading .h files all over the tree is actually a > > regression. > > 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. > > -Dimitry > 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. Also note that ports can do whatever they want as long they do not stomp on the word, my concern is about base only. -- Alexander Kabaev