Cross compiling with clion plus misc questions about internals

Hello, 

I would like to learn more about the possibility of using clion 2017.2.1 when invoking cmake with a toolchain file for cross compilation (e.g specifying -DCMAKE_TOOLCHAIN_FILE=<tc> in Build,Execution,Deployment->CMake)  

I have been able to get many aspects of a cross compilation flow working in clion (e.g. building, remote debugging, host machine darwin, target linux-x86-64) but it seems that clion's code-completion/analysis/navigation engine is pulling headers from compiler's default sysroot instead of the sysroot specified by the toolchain file (e.g it is ignoring -sysroot=<sys> being passed to compiler invocation)

Some details that might be helpful: I am using a custom built clang which has been built with a non standard sysroot -- this is not typical but I have had no problems with this per se and clion's code analysis works properly with a vanilla cmake project that uses this compiler via CMAKE_CXX_COMPILER, etc. -- clion somehow knows to pull headers from the proper sysroot that the compiler was built with.  

However, this being clang I can also  can also use the same compiler to cross compile for a different architecture and different sysroot.  As I said, when I do this via a toolchain file, clion's  building and  remote debugging all work fine, but the code analysis appears to be pulling headers from the compiler's default (non-standard) sysroot rather than the one specified in the toolchain file.  

---------------

This begs the question of exactly how is clion going about determining where it find system header files for a given compiler, as well as other things (such as is __APPLE__ defined for a given compiler -- something clion is clearly able to do)  -- all of this seems rather complicated to get right. 

It seems like clion might use some heuristics to parse the command line options that are used to invoke the compiler in the generated makefiles -- is this so?  

Whatever the case, clion seems to do a very good job of this normally -- for instance, in a test cmake project that uses

add_compile_options(-nostdinc)

clion correctly knows to not pull in the standard include headers.  

However in my scenario things are not quite right.  I'd be happy to provide more details, but if someone could shed some insight into how clion is internally working, I might be able to make progress that way.  

thanks, nehal