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