[cfe-dev] A couple of questions about include search paths

[mike-m]

On 2010-10-17, at 2:50 PM, Rafael Espíndola wrote:

> (sending again with the correct email address)
> 
>> But why do we need to do this? Why does GCC want a system header include to
>> precede it's builtin includes? I've been trying to contrive of a reason this
>> would be a good thing, even in the context of a cross compiler, and I can't
>> think of one.
> 
> I can't think of one too, but this is an area where it is probably
> better to have bug by bug compatibility with gcc. In fact, this was
> changed in 103912 so I assume the user had found a case where there
> was a dependency on the gcc way.
> 
>> Are you saying things are depending on this specific ordering?
>> (local/include before builtin)
>> If so, that might be a good reason to keep it even if there is no rationale
>> for this ordering. What things? How do they depend on it?
> 
> I am not sure. If I was the one designing these things I would
> probably not have a /usr/local :-) Mike, do you remember why you
> changed this?


The thought was if clang-builtin include position has to change, might as well place it consistent with gcc ordering; ie: after /usr/local/include and before /usr/include . As to why gcc searches /usr/local/include by default, I dare not speculate ;)

The details on why clang-builtin positioning needed to change (r103912) can be found in the following email. To summarize, particular versions of libstdc++ headers shipped with debian, ubuntu and fedora use #include_next <stddef.h> which dictated clang's stddef.h must be searched after libstdc++.

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100510/030245.html

--mike-m