Migrating to Bazel Modules (a.k.a. Bzlmod) - Maintaining Compatibility, Part 2
In the previous post, we reviewed guidelines for
maintaining compatibility with both Bzlmod and legacy WORKSPACE
builds, and
older and newer dependency versions. I promised that in this post and the next,
we'd discuss testing approaches to help ensure that this remains the case.
However, a discussion in the Bazel Slack workspace has revealed a Bzlmod and
legacy WORKSPACE
compatibilty issue I'd missed in the previous post. So in
this post, I'll discuss what to do with the class of legacy WORKSPACE
configuration macros that use Label
with computed repository names.
As we'll see, this one issue alone ended up meriting a substantial post in
itself. We'll cover adding dependency attributes to repository rules, generating
.bzl
files to resolve Label
s, chaining together module extensions, and using
macros in generated BUILD
files. The former two options are relatively
straightforward, but we cover the latter two options in case your use case
requires them.
Such legacy WORKSPACE
macros commonly seem to pertain to toolchain
configuration, selecting repositories to instantiate based on user defined
parameters. So we'll use a small example project to illustrate these solutions
as they apply specifically to toolchain configuration.
In the next post, I promise to get into the tasty testing stuff, in what promises to be the third of a four part trilogy.