Fabian Meumertzheim
Fabian Meumertzheim
Could be related to https://github.com/actions/runner-images/issues/10004#issuecomment-2153091255
I'll look into the rules_cc failures. In WORKSPACE land, it should depend on protobuf via its legacy name `com_google_protobuf`.
Sent https://github.com/bazelbuild/rules_cc/pull/255
@thesayyn Sorry, I forgot about this. Is this ready for review?
@thesayyn Took me a while not the general approach looks good to me. I like to see a workaround for bazelbuild/rules_cc#277 - have you tried to upstream it? This repo...
Since rules_java and rules_python both register toolchains , I don't see a way to remove them short of getting rid of the dependency from `bazel_tools` alltogether.
I think that if we remove it, projects that use `py_binary` without a `load` or dependency on `rules_python` would no longer find a Python toolchain.
I don't think there is much of a point in artifically cutting the dependency of a trivial C++ hello world on the rules_java repo. When the Java rules have been...
We do already have tests that verify that `cc_test` doesn't depend on certain unexpected tools: https://cs.opensource.google/bazel/bazel/+/0dbfaccaf5bee5ea7f11c01db1fc0cd1ca7f3810:src/test/shell/bazel/cc_integration_test.sh;l=1683. We could extend this to ensure that there are no unexpected rules_java deps without...
> Yeah, I'm supportive of the idea of being able to say "to the best of knowledge, my builds don't need Java and please error out if it touches anything...