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