bazel-contrib / bazel-contrib/toolchains_llvm

Feature: requirements instead of version specs.

Open
#473 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.