svn commit: r277803 - projects/clang360-import/lib/clang/include

[Alexander Kabaev]

On Wed, 28 Jan 2015 11:50:37 -0700
Ian Lepore <ian at freebsd.org> wrote:

> On Wed, 2015-01-28 at 13:39 -0500, Alexander Kabaev wrote:
> > On Wed, 28 Jan 2015 16:37:44 +0100
> > Dimitry Andric <dim at FreeBSD.org> wrote:
> > 
> > > On 28 Jan 2015, at 15:14, Alexander Kabaev <kabaev at gmail.com>
> > > wrote:
> > > > 
> > > > On Wed, 28 Jan 2015 08:42:48 +0100
> > > > Dimitry Andric <dim at 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
> 

I presume that is why we did the other day around ever since forever.
'Hell no' indeed.

--
Alexander Kabaev

-- 
Alexander Kabaev