rules_dotnet
rules_dotnet copied to clipboard
bazelbuild
[Next] Update rules-proto-grpc once next branch is merged
In recent versions you've switched to using toolchains and platforms for selecting the SDK version to be used. However, using a platform to resolve a single field in the toolchain is somewhat problematic for anyone who already has an existing platform, since it necessarily won't know about the SDK version.
Why were the config_settings not applied directly as constraints on the toolchain, rather than indirectly via the platforms? e.g bazel build //... --@io_bazel_rules_dotnet//dotnet/toolchain:sdk_version=3.1.100 along with target_settings on the toolchain definitions to restrict the resolved toolchain to one that matches the SDK version config setting.
@aaliddell Do you have some examples of toolchains that are configured this way? E.g. how do I make a constraint conifgurable via a flag?
And also, is it possible to use incompatible target skipping when using the approach you mentioned? E.g. in the repo there are targets that are only compatible with certain SDK versions.
These flags will be removed when we merge the next branch. I'm going to change this issue to track updating rules-proto-grpc once the next branch has been merged
Hello, is this issue about updating rules-proto-grpc so that the csharp-grpc-library etc. all work on the new @rules_dotnet instead of io_bazel_rules_dotnet?
Yes, we need to update rules_proto_grpc to use the latest release because we did multiple breaking changes recently
Closing this. These rules and rules_proto_grpc have changed significantly since it was created.