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

[Rafael Espindola]

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

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

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

One thing that could be done to clean up things a bit is split the
various config objects. Each looking something like

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