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

[Chandler Carruth]

On Sun, Oct 17, 2010 at 11:05 AM, Rafael Espindola <espindola at google.com>wrote:

> On 17 October 2010 03:46, Chandler Carruth <chandlerc at google.com> wrote:
> > First, does anyone know why the search paths take one of the following
> two
> > sequences?
> > If no C_INCLUDE_DIRS are provided:
> > 1) /usr/local/include
> > 2) <builtin-headers>
> > 3) <massive platform-specific location set>
> > 4) /usr/include
>
> This is to match gcc, except for the massive set which is a
> combination of every path used by different distros :-(
>

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.


> > If C_INCLUDE_DIRS is provided:
> > 1) /usr/local/include
> > 2) <builtin-headers>
> > 3) C_INCLUDE_DIRS
> > The thing that I don't get here is '/usr/local/include'. Why do we always
> do
> > this, unconditionally, and *before* the builtin headers? It means that if
> > your libc's 'limits.h' is in /usr/local/include, the wrong thing happens
> > with the builtin 'limits.h' include_next directive. I propose moving
> > '/usr/local/include' down to live with (and precede) '/usr/include'.
>
> I don't think that is a good idea. We should match the order that gcc
> uses.


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?

What could be done is replace the hardcoded /usr/local/include.
> The problem is that gcc has different behaviour when it is compiled as
> a regular compiler or a cross compiler. To handle both we can probably
> add a C_INCLUDE_DIR_PREFIX and search
>
> *) C_INCLUDE_DIR_PREFIX + "/local/include"
> *)  <builtin-headers>
> *) C_INUCLDE_DIR_PREFIX + "/include"
> *) C_INCLUDE_DIRS
>
> and for c++ add the c++ specific headers before that.
> C_INCLUDE_DIR_PREFIX should default to /usr and be ignore if it is
> empty.
>

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.


> > Second, there is no way to change the relative path used for the builtin
> > headers easily. The resource dir has 'include' appended to it, and
> neither
> > this relative path, nor the resource dir itself can be configured in any
> > way.
> > The resource dir seems to have two uses: finding static libraries on the
> > Darwin platform, and locating the builtin header files. I'd rather these
> > concepts were independent as one is Darwin-specific, and the other is
> needed
> > everywhere. We could still use the resource directory as a default for
> the
> > bultin header directory when on the Darwin platform. Others could specify
> > more likely defaults. My vague plan would be:
> > - create a dedicated option for tracking the bultin header location
> > - default it to <resource-dir>/include on Darwin, and possibly other
> > platforms initially
> > - allow compile-time default override to be specified much like we allow
> > C_INCLUDE_DIRS: BUILTIN_INCLUDE_DIR?
> > - investigate a better default for Linux systems; suggestions welcome
> here.
>
> 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..


> 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. =/ 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.


>
> class IncludeConfig {
>  std::vector<std::string> CXXIncludeDirs;
>  std::string EarlyIncludeDir;
>  std::string BultinDir;
>  std::vector<std::string> ExtraCIncludeDirs;
>  std::vector<std::string> FrameWorkIncludeDirs;
> };
>
> I think this can be use to represent the includes of every
> configuration we support. There would be one for each version of
> Darwin, one for each linux distro, etc. To make the construction easy
> we would need some factories. For example
>
> * Windows: Use  getWindowsSDKDir to find the correct sdk path and
> build the includeConfig.
> * Linux: Most linux distros can build a config with hard coded C path
> and custom C++ ones.
> * Configure time option.  Build a config base on the
> C_INCLUDE_DIR_PREFIX and similar variables.
> * As a hack, a "combined linux" config that merges the paths of every
> linux config. This would be the default unless the configure options
> were used.
>
> That is a lot of annoying refactoring, but should be somewhat on the
> path for having config files. It should also allow for a single clang
> binary to be used in different ways
>
> * clang -ccc-config=configure: This will use the contents of the
> configure options and can then use a custom libstdc++ for example
> * clang -ccc-config=linux-merge: The default hack of merging all linux
> paths
> * clang -ccc-config=ubuntu
>
> Currently if you set the configure options the produced clang cannot
> be used with the host includes for example :-(
>
> Cheers,
> --
> Rafael Ávila de Espíndola
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20101017/e0036f2e/attachment.html>