[cfe-dev] Default header search paths not included when compiling from libclang?

[Chandler Carruth]

On Tue, Nov 19, 2013 at 7:52 PM, Val Markovic <val at markovic.io> wrote:

> From what I can gather, it appears that when compiling a C++ file with the
> clang binary, clang will use some default header search paths. But when
> trying to do the same from libclang, it won't. Is this caused by the clang
> driver/frontend distinction (I don't know much about it)?
>

Yes, the Clang driver handles inspection of the host machine to determine
the appropriate set of header search, linker search, and other options to
use when compiling code.

I suspect that libclang doesn't do this almost entirely for historical
reasons. I think that the correct approach would be for libclang to include
the Clang driver library in its code and use it when forming "invocations"
from commandline flags where those flags are expected to be GCC-compatible
commandline flags for compilation.

Specifically, I think the implementation of clang_parseTranslationUnit and
clang_indexSourceFile (and any other entry points that accept a "command
line") should be implemented in terms of the Clang driver library.

The reason why this hasn't happened yet is (I suspect) because historically
many users were on systems and working with build systems where the
internal CC1-layer options which those routines support were simple and
sufficient to encode into the build system. However, that isn't the right
design at all.

Unfortunately, this will be a fairly significant amount of work. I suspect
the C++ interfaces in the Driver library are not the correct C++ interfaces
to make it easy to support both commandline usage and libclang usage. It'll
probably need refactoring at that level in addition to wiring it up to
libclang. More unfortunately, in order to not break the existing users we
should leave the entrypoints I mentioned in libclang functioning exactly as
they are but document that they accept the internal Clang CC1 commandline
interface, discourage the use of them, and point at entry points that do
the driver-based interpretation of commandline flags.

----

This is also the correct solution to the thread Sean Silva mentioned. It
also would solve a pile of other problems with libclang usage. It also
would make it much more feasible for IDE and other things to use a
libclang-style C interface for in-process code generation for C++ code. The
list goes on.

I don't know of anyone currently working on this though. =[

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140108/1e5f4b2d/attachment.html>