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

[Rafael Espíndola]

(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?

> This is not the problem I'm trying to solve. I'm trying to understand why we
> would ever want headers to override the builtin headers.
> If we really *have* to support this, I'm going to ask for an option at build
> or run time to disable it in order to make a more hermetic compiler.

The above description is effectively a compile time option since I
suggested ignoring C_INCLUDE_DIR_PREFIX if it is empty. What vanilla
gcc does is ignore the local dirs if it is built as a cross compiler.

>> Not sure if you need all that. All you should need for finding clang's
>> headers is path relative to itself. That is what gcc does. If it
>> resolves links or not is controlled by -no-canonical-prefixes.
>
> Have you looked at how this works in Clang? the relative path for the
> resource dir contains the clang version number in it. This is completely
> specialized for the Darwin packaging of it afaict..

I see. I would say that resource dir location system has to be smarter
or the installation structure more regular, but I am not familiar with
this particular part of the system.

>> One thing that could be done to clean up things a bit is split the
>> various config objects. Each looking something like
>
> While I don't have specific objections to this (other than my questions
> above), it's not what I'm working on right now. =/

Same problem I have. It never gets high enough in my priorities :-)

> I'd like to make the
> changes necessary to get the two issues I'm having making the includes
> hermetic fixed, and then if someone ese is interested in this cleanup,
> that'd be really cool. I won't have time to work on it for a month or two.

I think the smallest change you could make is to not include
/usr/local if C_INCLUDE_DIRS is set. That is, setting C_INCLUDE_DIRS
would imply gcc's behaviour when cross compiling. This would break
things for users that use C_INCLUDE_DIRS to create a host compiler for
an unusual host. Not sure if there are any such users.

Cheers,
--
Rafael Ávila de Espíndola