Respect include directories (`-I xyz`) and sysroot (`-isysroot xyz`) from `compile_commands.json`

[joshuawarner32]

Hi! I'm trying out c2rust on some old C code I found lying around and running into issues with c2rust giving errors about finding headers that don't happen to be in the same directory as the source.

This seems to happen with basically all .c files in the project, and will error out for the very first #include that looks for a file not in the same directory.

In most cases, this is a "standard" C header - but it also happens for anything that requires a -I compiler argument, even tho that is very clearly present in my compile_commands.json.

Typical example:

In file included from /Users/[user]/[redacted]/src/D/A.c:9:
In file included from /Users/[user]/[redacted]/src/D/A.h:11:
In file included from /Users/[user]/[redacted]/src/D/B.h:11:
/Users/[user]/[redacted]/src/D/Types.h:15:10: fatal error: cannot open file '/Users/[user]/[redacted]/src/D/string.h': No such file or directory
#include <string.h>
         ^
1 error generated.

I noticed that in c2rust-transpile/src/compile_cmds/mod.rs, the command is completely thrown away.

What's the recommended way to handle C projects that depend on non-default -isysroot values (/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk in my case; nothing fancy), or headers from external libraries?

It seems to me these arguments could easily be passed thru to AstExporter.cpp, where the actual clang invocation seems to be taking place. I can take a stab at this, if that seems reasonable.

[kkysen]

I believe clang reads the compile_commands.json itself, separately from c2rust-transpile, and clang should take into account the command/arguments fields and all of their include directories. So I'm not sure what the issue is here and why clang isn't looking in the right directories.