Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Host a toolchains repository #91

Open
alexeagle opened this issue Jan 22, 2024 · 2 comments
Open

Host a toolchains repository #91

alexeagle opened this issue Jan 22, 2024 · 2 comments

Comments

@alexeagle
Copy link
Contributor

Toolchains are like Providers:

  • 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.

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_features

@rickvanprim
Copy link

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.

@meteorcloudy
Copy link

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.

/cc @comius probably has more thoughts on this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants