D12331: Always use the clang builtin headers for the libclang version we use

Milian Wolff noreply at phabricator.kde.org
Sun Apr 22 07:47:09 UTC 2018


mwolff added a comment.


  To query what include files you got, the easiest really is to define the `KDEV_CLANG_DISPLAY_ARGS=1` env var. Then you'll see the command line we use for libclang, which includes the include paths. Defines could be queried by setting `KDEV_CLANG_DISPLAY_DEFINES=1`.

INLINE COMMENTS

> apol wrote in libclang_include_path.h.cmake:22
> Okay, doesn't make a lot of sense from my ignorant perspective. :P
> 
> It sounds to me like we should be telling about the system we are targetting. In fact, I'm surprised that sysroot isn't necessary.

I think your understanding of how it should be is the exact opposite of what's actually required :D

While parsing with libclang, we have to use the builtin headers from clang that exactly match the version of libclang we are using. With builtin headers, I mean e.g. /usr/lib/clang/6.0.0/include/xmmintrin.h - this is what we have to use when we parse with libclang 6.0.0. And this is independent of what compiler we actually use for the project we parse, this really is just related to the libclang version we use for parsing.

The reason is that these headers use builtins that are highly compiler and version specific. Trying to use GCCs builtins, or even those from a newer clang will fail in horrible ways (cf. all the bug reports we got).

This also explains why we don't need to specify the sysroot.

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D12331

To: mwolff
Cc: apol, mschwarz, brauch, kdevelop-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20180422/1b906c77/attachment.html>


More information about the KDevelop-devel mailing list