[cfe-dev] libclang c API will not find c++ system headers

[Per Bull Holmen via cfe-dev]

On Wednesday, August 21, 2019, 08:40:26 PM GMT+2, Jacob Carlborg via
cfe-dev <cfe-dev at lists.llvm.org> wrote:

> The per-compiled binaries available at http://releases.llvm.org are 
> configured differently compared to the binaries shipped by Apple. You 
> need to either manually (either on the command line or directly in your 
> application) add these paths or run an extra installation step to 
> install the headers in /usr/include where both binaries are looking. If 
> you run Clang with the "-v" flag and compare the one shipped by Apple 
> and the one provided at http://releases.llvm.org you will see the 
> difference.

Thank you. I've tried running with the -v option now, and there is some
difference. This might indicate that third-party plugin and tool
developers should link to the Apple-provided libclang on macOS.

However, I'm not sure it's needed, as I did make it work with the
precompiled binaries at http://releases.llvm.org/download.html simply by
calling clang_parseTranslationUnit2FullArgv, and providing the path to
the compiler executable in argv[0]. No extra steps necessary, no adding
paths, and no change of compiler options beyond those supplied by Xcode
(from the xcodebuild log).

I see some third-party developers of libclang-based plugins and tools
struggle with this, so I tried to do the same thing with a more complex
example and some Apple-specific system header includes that I know
vim plugin devs have struggled with, more specifically umbrella headers
in Apple Frameworks, and again it works smoothly right out of the box.
No errors reported, and I can traverse the AST with no problems.

I've seen plugin devs do all sorts of hacks to work around issues that
could have been solved this way, so I'd like to share a list ofwhat I did to make it work, in the faint hope that other third party
devs who run into the same problem read it:

1) Make sure you load the libclang you expect, and not some arbitrary
libclang the user might have in their system. Remember that you might
link to one version at compile time, yet your tool or plugin loads a
different version at runtime.

2) Do not move libclang out of the clang+llvm distribution folder, or
remove files that libclang expects to find there. It seems libclang
expects to find certain files relative to the lib location.

3) Use clang_parseTranslationUnit2FullArgv, and provide the path to the
compiler executable in argv[0]. Interestingly, it made no difference in
my case whether I used the one in the pre-compiled binaries folder
downloaded at http://releases.llvm.org/download.html, or the one in
Xcode's toolchain.

I suggest tools and plugins don't mangle with the command line options,
like adding paths or remove -isysroot etc. unless they have triedeverything above (and more), and it still doesn't work. Doing so creates
all kinds of future compatibility issues, and breaks the invariant that
users of your tool should always be able to depend on: If it works on
the command line, with the same clang version, and exactly the same
compiler options, then it should also work with your tool or plug-in.

I don't develop or maintain a cross-platform tool myself, so I can't
guarantee that this invariant always holds for libclang itself,
but I've seen cases where devs of such tools think they have to find
workarounds when it could have been solved by the above steps, and
haven't myself seen cases where it doesn't hold.
Per
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190822/273b39eb/attachment.html>