[cfe-dev] Extracting the include tree from a source file

[Paul Davey]

On Fri, Nov 19, 2010 at 9:31 PM, Bertjan Broeksema <broeksema at kde.org> wrote:
> Paul Davey wrote:
>
>> On Fri, Nov 19, 2010 at 8:21 AM, Bertjan Broeksema
>> <broeksema at kde.org> wrote:
>>> Nico Weber wrote:
>>>
>>>> Hm, this _might_ be because clang comes with a few standard headers,
>>>> see clang/lib/Headers. Maybe clang adds these to the search path
>>>> somehow. Adding a gentoo-specific include path is the correct fix in
>>>> this case.
>>>
>>> Yes it is because clang needs this standard headers installed in
>>> /usr/lib/clang/2.8/include (on linux of course, don't know about other
>>> platforms). From libs/Driver/Driver.cpp: (line 76 and further in 2.8)
>>>
>>> // Compute the path to the resource directory.
>>> llvm::sys::Path P(Dir);
>>> P.eraseComponent(); // Remove /bin from foo/bin
>>> P.appendComponent("lib");
>>> P.appendComponent("clang");
>>> P.appendComponent(CLANG_VERSION_STRING);
>>> ResourceDir = P.str();
>>>
>>>
>>> I don't really understand why. Moreover, I don't understand why
>>> AddGnuCPlusPlusIncludePaths in InitHeaderSearch.cpp is implemented as is.
>>> For example take:
>>>
>>> AddGnuCPlusPlusIncludePaths(
>>> "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.4/include/g++-v4",
>>> "x86_64-pc-linux-gnu", "32", "", triple);
>>>
>>> The directory above (i.e.
>>> /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/) also contains the
>>> headers which are in /usr/lib/clang/2.8/include. So I wondered why
>>> AddGnuCPlusPlusIncludePaths, doesn't add this path too so that the clang
>>> include directory is not required.
>>>
>>> This might be Gentoo specific, meaning that for other distros the current
>>> code *does* find the standard headers and therefore doesn't need the
>>> clang include path. If so, please tell me. In that case for the Gentoo
>>> adding a line like:
>>>
>>> AddPath( "/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.4/include/"
>>> , System, true, false, false );
>>>
>>> would remove the need for custom apps to add the clang include dir.
>>>
>>> Cheers,
>>>
>>> Bertjan
>>>
>> The headers in lib/clang/2.8/include are clang header, the ones for
>> gcc are gcc header, the ones for clang should be used with clang.
>> That function only adds the C++ header path which is actually for
>> libstdc++ not part of gcc the other headers are part of gcc and
>> shouldn't be messed with AFAIK.
>
>> As you said the driver computes the
>> path to clangs headers relative to itself, perhaps this should be
>> separated into a separate function.
>
> Yes that would be more convenient, or as a define in the config.h file.
> Anything not relying on the clang executable and not requiring any path
> calculations by the client would be okay I guess.
>
> Cheers,
>
> Bertjan

It uses the path calculations for a good reason, you can place the
clang executable anywhere and as long as those files are in that
relative location it will work, this is something that should happen.
I understand this can cause other applications that use clang as a
library some problems, but they can either include these files in the
same relative path to themselves and a convenience function be
provided, or InitHeaderSearch have a function added to add the
standard install location for use by 3rd party apps perhaps.