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

[Manuel Klimek]

ping chandler...

On Thu, Nov 28, 2013 at 4:10 PM, Manuel Klimek <klimek at google.com> wrote:

> +chandler, as he knows a lot about the driver...
>
> On Wed, Nov 20, 2013 at 1:52 AM, 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)?
>>
>> Specifically, I'm talking about this issue affecting the YouCompleteMe
>> plugin: https://github.com/Valloric/YouCompleteMe/issues/303
>>
>> So, is there a way to get libclang to use the same header search paths
>> that the clang binary does? If not, why not and could this be changed in
>> future versions of libclang?
>>
>> If there's no way to get libclang to use the same header search paths by
>> default, is there a way to extract them out of the libclang API so that the
>> paths can then be provided in other libclang API calls? If not now, could
>> libclang be changed to support this in the future?
>>
>> The current situation where libclang users are forced to recreate the
>> default header search path logic for every OS is incredibly frustrating.
>> YCM can't even call out to clang to extract the headers out of it with
>> "echo | clang -v -E -x c++ -" because clang might not even be installed on
>> the machine. We only have libclang to work with.
>>
>
> I guess it would make sense to add some way to query the driver logic to
> libclang.
> What I don't know enough about is relative to which "clang" version the
> driver should search in that case - perhaps the right solution is to either
> hand one in from the outside, or use the unix search path?
>
> Cheers,
> /Manuel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140108/b0eab0e6/attachment.html>