bazel-contrib / bazel-contrib/rules_cuda

if_cuda_toolkit_version_ge uses the maximum declared version inside every component repo

Open
#497 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Starlark
Stars
122
Forks
73
Avg merge
7h 34m
Merged PRs (30d)
7

Description

Every component repo loads `@cuda//:defs.bzl` for `if_cuda_toolkit_version_ge`, but that file is generated once for the `@cuda` toolkit repo with a single stamped version:

`cuda/private/templates/defs.bzl.tpl`:

```starlark
def if_cuda_toolkit_version_ge(version, if_true, if_false = []):
ctk_version = (%{version_major}, %{version_minor})
```

With several `cuda.redist_json` declared, that version is the maximum one (the same "Always use the maximum version so the toolkit includes all components" choice behind #477). So inside a non-maximum component repo the function answers for a version that repo is not.

The visible effect is on the CCCL targets, whose layout differs across the CUDA 12/13 boundary. Declaring 13.x and 12.8.1 and inspecting the 12.8.1 repo on current main:

```
$ bazel cquery '@@rules_cuda++toolchain+cuda_cccl_linux_x86_64_12_8_1//:thrust' \
--output=build --@rules_cuda//cuda:version=12.8.1 | grep includes
includes = ["cccl/include/cccl"]
```

That is the CUDA 13 path, but this is the 12.8.1 component, where the headers are at `cccl/include`. `cub` and `libcudacxx` resolve the same way, and anything reaching them gets an include path that does not exist.

This is distinct from #477, which fixed the version the *toolchain* reports. Here the wrong version is baked into a loading-phase helper, so it cannot be a `select()`: `includes` is computed while the BUILD file is evaluated, long before the configuration is known.

The fix I would expect is for each component repo to generate (or otherwise obtain) its own `defs.bzl` with its own version, rather than sharing the toolkit's. `cuda_component` already receives a `version` attribute and writes it to `version.json`, so the value is available where it is needed.

Noticed while working on #496, which sidesteps it by testing a single declared version. Happy to send a PR if you would like it fixed this way; I did not want to guess at the layering, since it changes what every component repo generates.

Contributor guide

Open the contributing guide

Research direction

Start with cuda/private/templates/defs.bzl.tpl and trace how cuda_component generates each component repository and its version.json. Verify the change with the 12.8.1 and 13.x component repos using the shown bazel cquery; done means each repo's if_cuda_toolkit_version_ge selects its own version and CCCL, cub, and libcudacxx use existing include paths.

Written by the indexing model from the issue text.

Assessment

Domain
build-system
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.