strip_include_prefix usage in cc_library

[jinxin song]

Hi all,

I would like to ask about the proper usage of strip_include_prefix for C/C++ project. From what I understand from bazel documentation(https://bazel.build/tutorials/cpp-use-cases?hl=en#add-include-paths), that header is preferred to be included as path relative to workspace root or using copts for paths where full relative path can not be used. But using copts also has the disadvantage that it is compiler specific and it won't add -I to transitive dependencies. 

The other 2 options we found with cc_library is to use:

includes: it works with transitive includes but the header is included as system includes and will hide the compiler warnings.(This is no go for us because we want to reach 0 compiler warnings)

strip_include_prefix: it works perfectly from the build perspective->  headers is included transitively, and is included with -I flag. The problem with it is that it creates _virutal_includes which is symlinked to the original header in source, but these _virtual_includes path is causing issues with remote debugging, or certain ide tools(e.g. clang-format or clang-tidy will look for configuration files from parent folder, but when opening the file from _virtual_include path those files can not be found).

My main questions are as follows:

- If we are not able to specify a include path as relative path to workspace root, and we want to make the include path transitive, is strip_include_prefix the only option we have?

- If strip_include_prefix is the only option, is there any possibility that we can get rid of these _virtual_includes path?

- Is there any other possibilities that allows us to  specify a include path while making it transitive and not system includes?( we are thinking of implement own cc_library rule or edit in toolchain configuration in the way that include path added via includes attributes is replaced with -I flag.) 

Thanks in advance!

[ai...@google.com]

This is really a question for stack overflow or an issue in rules_cc. The bazel-dev list is for discussion about bazel implementation and direction.