Fabian Meumertzheim
Fabian Meumertzheim
CC @meteorcloudy, who is working on making `rules_java` the source of truth for Java toolchains (see https://github.com/bazelbuild/bazel/pull/18423). Given that, I'm pretty sure the correct answer is `rules_cc`.
Could we instead do what you suggested in https://bazelbuild.slack.com/archives/CDBP88Z0D/p1746198402121529?thread_ts=1746189567.685639&cid=CDBP88Z0D and add the configured proto and/or grpc compilers depending on the number of service and/or message definitions?
@sgowroji Still relevant, although it may be fixed by toolchainifying proto rules instead.
CI is red
@faximan Could you rebase and resolve the conflict?
But isn't the default to inherit the current process environment, which should be equivalent to passing `os.environ` except for filtering out these weird variables?
I sent out https://github.com/bazelbuild/bazel/pull/26355, which overhauls the features and documents them.
One caveat: This would turn converting a rule into a macro a breaking change unless this behavior is taken into account.
> But in this case, wouldn't the answer be that when writing a new macro to replace a rule, you have the macro return the label of the main target?...
Case 1 should probably either be consumed as a Bazel module directly or brought in with `clean` mode. Do you have an example for this case? For case 2 I'm...