The mylang_register_toolchains macro invokes toolchains_repo which generates a toolchain target for each platform as well as a resolved_toolchains target that acts as an alias for the currently resolved toolchain. This is intended as a workaround for https://github.com/bazelbuild/bazel/issues/14009 to expose make variables to rules that want to directly depend on the "mylang" toolchain, e.g. genrule.
Because the resolved_toolchains target is generated as part of toolchains_repo users have to know and use the name given to that external workspace. E.g. in the example setup a user would have to use the label @mylang1_14_toolchains//:resolved_toolchain. This is problematic:
If the target is needed by a Bazel workspace other than the main workspace, that workspace has to either anticipate the name that the main workspace will assign to that toolchain repository, or import its own "mylang" toolchain which may conflict with that needed by the main workspace or another workspace.
If a project needs a custom toolchain and doesn't invoke mylang_register_toolchains or toolchains_repo at all, then there will be no resolved_toolchains target.
There is no reason why resolved_toolchains has to part of or linked to toolchains_repo or mylang_register_toolchain. I propose that resolved_toolchains should be defined in com_myorg_rules_mylang directly, instead.
The
mylang_register_toolchainsmacro invokestoolchains_repowhich generates atoolchaintarget for each platform as well as aresolved_toolchainstarget that acts as an alias for the currently resolved toolchain. This is intended as a workaround for https://github.com/bazelbuild/bazel/issues/14009 to expose make variables to rules that want to directly depend on the "mylang" toolchain, e.g.genrule.Because the
resolved_toolchainstarget is generated as part oftoolchains_repousers have to know and use the name given to that external workspace. E.g. in the example setup a user would have to use the label@mylang1_14_toolchains//:resolved_toolchain. This is problematic:mylang_register_toolchainsortoolchains_repoat all, then there will be noresolved_toolchainstarget.There is no reason why
resolved_toolchainshas to part of or linked totoolchains_repoormylang_register_toolchain. I propose thatresolved_toolchainsshould be defined incom_myorg_rules_mylangdirectly, instead.