You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The toolchain_type definition must be canonical. Everyone must agree on the symbol to use, e.g. @someones_repo//toolchains:grep_toolchain
A concrete toolchain might be defined in one or more rulesets, or end-user monorepos might declare their own (e.g. build from source with specific flags or target platform)
A toolchain might be consumed in one or more rulesets, which shouldn't have to define it themselves. Many rulesets would like to be able to rely on a hermetic grep executable for example. They could leave it for users to choose one of the concrete toolchain implementations.
Currently the world is broken because rulesets that define a concrete toolchain (e.g. the tar_toolchain in aspect bazel-lib) ALSO define a toolchain_type symbol.
I think there are 3 pieces that would need to be part of a centralized repo, the toolchain_type, any provider definitions that get used in the ToolchainInfo, and the rule that constructs that ToolchainInfo.
In general, I agree this is the right direction. However, we also need to think about how to migrate existing definitions to this central repo in a less intrusive way for users. For example, when we moved most of java toolchains from bazel_tools to rules_java, we had to leave the java toolchain in bazel_tools to be backwards compatible.
Toolchains are like Providers:
toolchain_type
definition must be canonical. Everyone must agree on the symbol to use, e.g.@someones_repo//toolchains:grep_toolchain
grep
executable for example. They could leave it for users to choose one of the concrete toolchain implementations.Currently the world is broken because rulesets that define a concrete toolchain (e.g. the
tar_toolchain
in aspect bazel-lib) ALSO define atoolchain_type
symbol.On Slack, @rickvanprim proposed that a new
toolchains
repo could be created. I think it's a good idea. Note that it must be suitable to be a common dependency of many rulesets, like https://registry.bazel.build/modules/bazel_featuresThe text was updated successfully, but these errors were encountered: