[cfe-dev] A couple of questions about include search paths
Chandler Carruth
chandlerc at google.com
Sun Oct 17 00:46:46 PDT 2010
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
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'.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20101017/5a135e65/attachment.html>
More information about the cfe-dev
mailing list