Date: Wed, 28 Jan 2015 11:50:37 -0700 From: Ian Lepore <ian@freebsd.org> To: Alexander Kabaev <kabaev@gmail.com> Cc: Benjamin Kaduk <bjkfbsd@gmail.com>, svn-src-projects@freebsd.org, "src-committers@freebsd.org" <src-committers@freebsd.org>, Dimitry Andric <dim@FreeBSD.org> Subject: Re: svn commit: r277803 - projects/clang360-import/lib/clang/include Message-ID: <1422471037.15718.64.camel@freebsd.org> In-Reply-To: <20150128133946.7243a0fc@kan> References: <201501271925.t0RJPem3010417@svn.freebsd.org> <CAJ5_RoAvww7xFsSTBMPDThYsbpVbxOs11nWE=eEXpJRFx_kyww@mail.gmail.com> <20150127191134.4fe3a17f@kan> <F7477A20-BC56-4CF9-8520-77F7BFD4B72E@FreeBSD.org> <20150128091457.1b0ea3a7@kan> <2DA71591-EE38-42F9-983F-8E711CA36A75@FreeBSD.org> <20150128133946.7243a0fc@kan>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2015-01-28 at 13:39 -0500, Alexander Kabaev wrote: > On Wed, 28 Jan 2015 16:37:44 +0100 > Dimitry Andric <dim@FreeBSD.org> wrote: > > > On 28 Jan 2015, at 15:14, Alexander Kabaev <kabaev@gmail.com> wrote: > > > > > > On Wed, 28 Jan 2015 08:42:48 +0100 > > > Dimitry Andric <dim@FreeBSD.org> 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 <blah> /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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1422471037.15718.64.camel>