[cfe-dev] clangd/libclang: how to emulate other compilers?

[Manuel Klimek via cfe-dev]

On Tue, Apr 17, 2018 at 8:02 PM Milian Wolff via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hey all,
>
> how does clangd or other users of the libclang handle situations where you
> want to parse code that is dependent on a certain other compiler or
> compiler
> environment? The most common scenario being embedded projects that rely on
> the
> compiler-builtin defines and include paths to find the sysroot include
> paths
> and such.
>

I'm not sure I understand what you mean - do you mean the compiler has
builtins that clang doesn't provide and relies on their existence?

Generally, you'll want to use the builtin defines and includes from clang
(at the point at which you compiled libclang), but the standard library and
so forth that the system is using. Clang should be able to find that given
the right flags.


> For KDevelop, which is using libclang, we have tried to build a sort of
> emulation layer that originally yielded good results. The approach is as
> followed:
>
> 1) We use the actual compiler that is used to compile a given project,
> e.g.
> gcc, arm-none-eabi-gcc, ...
>
> 2) We take this compiler and query it for its builtin defines:
> /usr/bin/gcc -xc++ -std=c++11 -dM -E - < /dev/null
>
> 3) And also query the include paths:
> /usr/bin/gcc -xc++ -std=c++11 -v -E - < /dev/null
>
> 4) Then for the libclang calls to clang_parseTranslationUnit2 we pass `-
> nostdinc -nostdinc++` followed by the defines and includes we got from 2)
> and
> 3).
>
> Now, for simply things this actually worked quite well. But once you
> include a
> file that heavily relies on the compiler, such as all the SIMD intrinsic
> headers, you are easily drowning in parse errors. And once you have too
> many
> parse errors, clang will just give up. We have tried to workaround this
> via
> compatibility headers such as [1], but it keeps breaking.
>
> More recently, we now also got bug reports where the user system has
> clang3
> and they use that to to compile the code, but then download a KDevelop
> AppImage built against libclang v5 (e.g. via AppImage). Once again this
> easily
> yields tons of parse errors when encountering system headers that are
> using
> intrinsics specific to clang v3.
>
> I am now thinking about removing the emulation layer described above. But
> then
> it will be essentially impossible to work on a lot of embedded projects
> which
> rely on the cross compiler defines and include paths...
>
> So, once again - how do other users of libclang handle this scenario? What
> is
> the plan for clangd in this regard?
>
> Thanks
> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de_______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180418/964a5233/attachment.html>