bazel-contrib / bazel-contrib/toolchains_llvm
Feature: requirements instead of version specs.
- Dominant language
- Starlark
- Stars
- 371
- Forks
- 283
- Avg merge
- 1d 55m
- Merged PRs (30d)
- 25
Description
It sometimes does not matter exactly which version you get on which platform. What matters is that you get a version within a range that your code supports. And sometimes you need to exclude version from these rangers (for instance we had to exclude 19.1.7).
For instance the following would find any version starting with 19.1.1 but would not allow 19.1.7 (did not work for us) and would not accept any version starting with 20. Effectively allowing any newer version in the 19 branches but skipping 19.1.0 and 19.1.7.
```
llvm = use_extension("@toolchains_llvm//toolchain/extensions:llvm.bzl", "llvm", dev_dependency = True)
llvm.toolchain(
name = "llvm_toolchain_llvm",
llvm_version = "latest:>=19.1.1,!=19.1.7,<20",
)
use_repo(llvm, "llvm_toolchain_llvm")
```
If the version is simply `"latest"`, then the toolchains will automatically pick up the latest viable distribution.
I implemented a proof of concept in two stages:
* PR [471](https://github.com/bazel-contrib/toolchains_llvm/pull/471) implements only "latest" support.
* PR [472](https://github.com/bazel-contrib/toolchains_llvm/pull/472) implements "latest" and requirements as shown above.
The missing piece would be the ability to provide a custom list or distributions. That would ultimately allow people to add new versions just by running the hash script and dumping the results into their MODULE.bazel, WORKSPACE or dependency.bzl files. That would mean [issues like #464](https://github.com/bazel-contrib/toolchains_llvm/issues/464) would simply be answered by pointing to the docs. In fact we could have an up-to-date extra list readily available in the repo.
Contributor guide
Research direction
Start by reviewing PRs #471 and #472, which cover the proposed "latest" and version-requirement behavior. Then determine how custom distribution lists would be supplied through MODULE.bazel, WORKSPACE, or dependency.bzl. Done means the toolchain supports the requested version ranges and exclusions along with user-provided distributions.
Written by the indexing model from the issue text.
Assessment
- Domain
- build-system
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100