bazel: Bazel 5.0.0 breaks TensorFlow's sanity test
Description of the problem / feature request:
Bazel 5.0.0 breaks TensorFlow’s sanity test.
Bugs: what’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
$ git clone //github.com/meteorcloudy/tensorflow.git
$ cd tensorflow
$ git fetch origin query_reproduce
$ git checkout query_reproduce
$ bazel-5.0.0 query --noimplicit_deps -- "deps(//tensorflow/... - kind("android_*", //tensorflow/...))"
The error message will be
ERROR: /usr/local/google/home/pcloudy/workspace/tensorflow/tensorflow/lite/experimental/acceleration/configuration/BUILD:74:24: every rule of type java_lite_proto_library implicitly depends upon the target '@com_google_protobuf//:javalite_toolchain', but this target could not be found because of: no such target '@com_google_protobuf//:javalite_toolchain': target 'javalite_toolchain' not declared in package '' (did you mean 'java_toolchain'?) defined by /usr/local/google/home/pcloudy/.cache/bazel/_bazel_pcloudy/d2f15366e3b15100d3593f2d595721a3/external/com_google_protobuf/BUILD
which means --noimplicit_deps
is not correctly filtering out implicit dependency “@com_google_protobuf//:javalite_toolchain”.
What operating system are you running Bazel on?
Linux
Other information
- TensorFlow sanity test: https://cs.opensource.google/tensorflow/tensorflow/+/master:tensorflow/tools/ci_build/ci_sanity.sh
- Directly running
bazel query --noimplicit_deps -- "deps(//tensorflow/lite/experimental/acceleration/configuration:configuration_java_proto_lite)"
in a clean workspace won’t reproduce the issue, but if you run it afterbazel-5.0.0 query --noimplicit_deps -- "deps(//tensorflow/... - kind("android_*", //tensorflow/...))"
, then it outputs the same error. - A bisect points to https://github.com/bazelbuild/bazel/commit/9cb59369a84d9328c2929eefcb58c1b972ab15f2, but I don’t see any connection.
About this issue
- Original URL
- State: open
- Created 2 years ago
- Comments: 19 (18 by maintainers)
Fair point on the help text. I didn’t check, but it’s very possible it predates
query
’s entire implementation! Specifically, the Skyframe-poweredquery
that relies onTransitiveTargetFunction
as described.This definitely piqued my interest so I’d like to continue trying to help.
Otherwise I’ll ping @haxorz again with this specific Skyframe question: do you know why a Skyframe error from a failed
TransitiveTargetFunction
evaluation would get suppressed? My comment at https://github.com/bazelbuild/bazel/issues/14639#issuecomment-1029567201 shows specific callstacks. I’ve verified the error always happens. The only difference is whether or not the user sees it.@meisterT and
team-Performance
may have ideas onquery
’s implementation and how it propagates errors.@bazel-io fork 5.1