Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
When generating a symlink in _virtual_includes, add the original head…
…er to the 'allowed to use' set too When a cc_library 'a' makes use of strip_include_prefix, bazel creates a symlink for the hdrs at bazel-out/.../bin/_virtual_includes/a/ Later, bazel passes -I bazel-out/.../bin/_virtual_includes/a/ to the command line to tell the compiler where to look for those headers. For each header in hdrs, bazel will either put the header artifact itself in a set of 'allowed to use' headers, or, in the case of strip_include_prefix usage, bazel will add the symlink to the header under bazel-out/.../bin/_virtual_includes/a/ as 'allowed to use'. When searching for headers, the compiler will do the following (Taken from https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html): 1. For the quote form of the include directive, the directory of the current file is searched first. 2. For the quote form of the include directive, the directories specified by -iquote options are searched in left-to-right order, as they appear on the command line. 3. Directories specified with -I options are scanned in left-to-right order. ... In the case of the following cc_library: ``` cc_library( name = 'foo', hdrs = ["lib/foo.h"], srcs = ["lib/foo.cc"], strip_include_prefix = 'lib', ) ``` if foo.cc includes foo.h as #include "foo.h" the compiler will find the header in step 1 of the search, thus will use the original header and not the symlink. The compiler will note this in the .d file. Bazel however added the symlink in the list of 'allowed to use' headers, so at some point it will error out with "undeclared inclusion(s) in rule" error due to the discrepancy. This cl tells bazel to add the original header in the 'allowed to use' headers even when it generates a symlink in the _virtual_includes directory. Fixes bazelbuild#3828 bazelbuild#6337 RELNOTES:None. PiperOrigin-RevId: 344240730
- Loading branch information