Support cross compiling / No std builds

[athei]

When using cquery for cross compilation I have the problem that it adds the pathes of the system compiler to the include path and not the ones of the cross compiler. To fix this I propose the following changes:

• If the --sysroot flag is detected for a file the built-in specs of that cross compiler should be used instead of the system compiler ones.

• If -nostdlib flag is detected no std lib include pathes should be added.

[jacobdufault]

If supporting something like this is not complicated than SGTM, but there is a limit to what the auto-setup logic can do without completely re-implementing clang command line parsing.

[ghost]

If you use gcc to cross-compile then include paths of the system compiler are not the only problem you will find. cquery uses libclang in order to compile translation units and for clang to work in cross-compilation you need additional flags as not only --sysroot flag is required - you also need --target and --gcc-toolchain. cquery may parse files properly but it will definitely report a lot of errors from your headers.

[athei]

I use cquery mainly for embedded kernel development. It works better than any other tool even with the wrong target and sysroot. I just set some endian defines. Of course I have many errors but I do not care as long as jumping to definition/references works.

I agree that it is problematic to duplicate all the clang command line parsing. What about extracting all the information from the command compiler binary by asking it for its machine and sysroot without looking at the other flags. The only thing is the -nostd thing that cannot be extracted from that.

[jacobdufault]

I agree that it is problematic to duplicate all the clang command line parsing. What about extracting all the information from the command compiler binary by asking it for its machine and sysroot without looking at the other flags. The only thing is the -nostd thing that cannot be extracted from that.

We currently extract system include headers in this manner.

@athei if you have your cross compiler be an path (ie, /bin/cross-gcc) in your compile_commands.json cquery will query that compiler for system includes first.

[athei]

Nice! I create the compile_commands.json without the command only with arguments. I will fix my script.

Still, this is only headers, --target and --gcc-toolchain is still missing, right?

[jacobdufault]

I don't recall if cquery looks at command, the first value of arguments is supposed to be a compiler, ie, for me it is

"command": "/work/goma/gomacc ../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF obj/apps/apps/app_lifetime_monitor.o.d -DV8_DEPRECATION_WARNINGS -DDCHECK_ALWAYS_ON=1 -DUSE_UDEV -DUSE_AURA=1..."

The compiler (clang++) is a path.

[bstaletic]

For figuring out the system headers, cquery does take into account --gcc-toolchains, --sysroot and -nostdlib.

https://github.com/cquery-project/cquery/blob/master/src/project.cc#L123-L128

[athei]

But only when supplied as extra arguments and not when supplied in compile_commands.json, right?

[bstaletic]

No, cquery passes results.args as the flags for GetSystemIncludes. The results.args is populated by cquery by sanitizing your flags. Then cquery loops through the sanitized flags and cherry-picks what flags to keep for the system header discovery.

[athei]

I don't recall if cquery looks at command, the first value of arguments is supposed to be a compiler, ie,

I tried that (with --check). Unfortunately it cquery ignores the command. It would help alot if it would use it.

[athei]

For figuring out the system headers, cquery does take into account --gcc-toolchains, --sysroot and -nostdlib.

At least for me this does not work. I have -nostdinc in my arguments and at the end -isystem/usr/lib/gcc/x86_64-linux-gnu/7/include -isystem/usr/local/include -isystem/usr/lib/gcc/x86_64-linux-gnu/7/include-fixed -isystem/usr/include/x86_64-linux-gnu -isystem/usr/include is added. I see them both at the same time using --check.