[cfe-dev] clang_parseTranslationUnit2(), "true", and libclang's header search path

[W. Michael Petullo via cfe-dev]

[...]

>> All of this appears to follow from my program failing to find stdbool.h. I
>> used strace to discover that libclang seems to search
>> 
>> 	/usr/local/include/,
>> 	/usr/include/, and
>> 	/include/
>> 
>> but not
>> 
>> 	/usr/lib64/clang/3.9.1/include/.
>> 
>> The last directory is where clang installed its headers, so I am
>> surprised that libclang does not look there.
>> 
>> Is the expectation that I discover /usr/lib64/clang/3.9.1/include/
>> and pass -I/usr/lib64/clang/3.9.1/include/ to my program?

[From Jacob Carlborg:]
> In my tool I solved this by embedding some of the internal header files into
> the executable. Then pass them to libclang as virtual files using
> CXUnsavedFile 
 
[From Emilio Cobos Álvarez:]
> FWIW I've seen this problem before too. The rust libclang bindings
> "solve" this just trying to run |clang -E -x <lang> -v|, and parsing the
> output, which is not only somewhat overkill, but also a fairly hacky
> solution. It works well in practice though, AFAICT (I don't maintain
> that library, but I use it).

Both of these solutions seem a bit kludgy. Because the former hard-codes
a header in the binary which uses clang, a system upgrade might result in
an inconsistency between the binary and the filesystem copy of the header.
The latter seems kludgy too for the reason Emilio described.

Another idea is to find, e.g., /usr/lib64/clang/3.9.1/include/ at
./configure time and set a string in the program which uses libclang. But
this too is asking for an inconsistency: The path might change if the
clang installation is updated without reconfiguring and rebuilding
the program.

>> Why does libclang not search clang's header directory by default?

[From Emilio Cobos Álvarez:]
> I think it doesn't seem unreasonable, and if including them by default
> would be breaking (which I guess it would), it may make sense to
> retrieve the default include paths as a CXStringSet or something of the
> sort.
> 
> That being said, I'm not sure how difficult to implement it would be, or
> even if it's feasible without a clang binary around?

I am surprised that this is not already the case since the libraries
ship with clang itself. Does anyone else have any comments as to why,
e.g., /usr/lib64/clang/3.9.1/include/ is not already known to libclang?
At the very least clang could install a configuration file which contains
the location of these internal headers.

-- 
Mike

:wq