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

[Argyrios Kyrtzidis]

On Jan 8, 2014, at 1:43 PM, Chandler Carruth <chandlerc at google.com> wrote:

> 
> 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.

Not sure why you have this impression but these libclang functions do not accept CC1 options, they accept driver options.
They depend on clang::createInvocationFromCommandLine(); if there's some difference between how options are handled between clang and libclang this is the place to investigate.

> 
> ----
> 
> 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
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

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