bazel: Bazel CI: Android Testing is failing on Windows with Bazel@HEAD
ERROR: D:/b/ny24af4c/external/bazel_tools/src/main/native/windows/BUILD:42:1: Couldn't build file external/bazel_tools/src/main/native/windows/_objs/windows_jni.dll/file-jni.obj: undeclared inclusion(s) in rule '@bazel_tools//src/main/native/windows:windows_jni.dll':
--
| this rule is missing dependency declarations for the following files included by 'external/bazel_tools/src/main/native/windows/file-jni.cc':
| 'D:/b/hh7flgnl/execroot/__main__/bazel-out/host/genfiles/external/bazel_tools/src/main/native/jni_md.h'
<del>Culprit Finder says d235a06ede2247479dd8e5c315d55df4d657a618 is the culprt </del>
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 22 (22 by maintainers)
Commits related to this issue
- C++ compilation: flag for header-validation debug Add the --[no]experimental_header_validation_debug flag. This flag tells Bazel to print extra debugging information when a C++ compilation action fa... — committed to laszlocsomor/bazel by laszlocsomor 6 years ago
- Make ShowIncludesFilter ignore execroot differences Fixes https://github.com/bazelbuild/bazel/issues/6847 This change is for making including scanning work on Windows for builds with rem... — committed to luca-digrazia/DatasetCommitsDiffSearch by deleted user 2 years ago
I believe I have understand the underlying problem. cbacbb9 actually revealed a header checking bug when using remote execution. Before cbacbb9, we filter the original output during the actual execution of the compiling action, which means the store action output is already filtered. In later builds, when we reply the output from the stored file due to remote cache hit, the output is already filtered, thus we capture no header file dependencies anymore.
After cbacbb9, we store the output to file first, so no matter remote cache is hit or not, we always parse the original output. Because the output could contain absolute path (execroot) from a different machine, we got this problem.
I’m working on a fix to remote the execroot prefilx from include file paths in the output. We’ll see if that works.
Let me take a look!
@laszlocsomor Thanks for looking into this! Your conclusion is very plausible, I suspect it’s caused by https://github.com/bazelbuild/bazel/commit/cbacbb9083efab215c1c8015f7488cf8b2747889.
@ulfjack confirmed we do cache the action’s outErr in remote cache. But we haven’t understand why it’s not happening before.
I see, but it’s better we use
--output_user_rootflag also forbazel info. I’ll send a change.