bazel-contrib / bazel-contrib/rules_cuda
cccl_headers uses the pre-CUDA-13 include path, so <thrust/...> does not resolve on CUDA 13
- Dominant language
- Starlark
- Stars
- 122
- Forks
- 73
- Avg merge
- 7h 34m
- Merged PRs (30d)
- 7
Description
On a CUDA 13 toolkit, `@cuda//:cccl_headers` sets `includes = ["cccl/include"]`, but CUDA 13 moved the CCCL headers one level deeper, to `cccl/include/cccl/`. Anything including `` (or ``, ``, ``) through that target fails to find the header.
The per-library targets in `cuda/private/templates/BUILD.cccl` already handle this correctly:
```starlark
includes = if_cuda_toolkit_version_ge(
(13, 0),
["%{component_name}/include/cccl"],
["%{component_name}/include"],
),
```
But `cccl_headers` is not generated from that fragment. It comes from the generic `cuda/private/templates/BUILD.dctk_comp`, which is version-unaware and always emits the shallow path:
```starlark
cc_library(
name = "%{component_name}_headers",
hdrs = [":%{component_name}_header_files"],
includes = ["%{component_name}/include"],
)
```
This also reaches `@cuda//:cuda_headers`, since `BUILD.dctk_cuda` aggregates every `_headers` target.
The `hdrs` glob (`cccl/include/**`) does pick the files up, so the headers are present -- only the include path is wrong. `#include ` resolves; `#include ` does not.
Observed with a `cuda.redist_json` toolkit at 13.2.2 on `linux-x86_64`, in the generated `@cuda_cccl_linux_x86_64_13_2_2//:cccl_headers`. Depending on `@cuda//:thrust` instead is a working workaround, since that target is version-aware.
This looks independent of the multi-version work -- the generic fragment is version-unaware for a single declared version too -- but I have only tested the redist path, not a local CTK install.
Happy to send a PR if you'd like it fixed in `BUILD.dctk_comp` (guarding the generic target) versus having the `cccl` fragment override its own `_headers` target -- I don't want to guess which layering you'd prefer.
Contributor guide
Research direction
Start with cuda/private/templates/BUILD.dctk_comp and compare its generic component_headers rule with the version-aware logic in cuda/private/templates/BUILD.cccl; also inspect cuda/private/templates/BUILD.dctk_cuda to see how cuda_headers aggregates the targets. Verify the generated cccl_headers target for CUDA 13 and an older toolkit: both unprefixed and cccl-prefixed includes should resolve while existing pre-CUDA-13 behavior remains intact.
Written by the indexing model from the issue text.
Assessment
- Domain
- build-system
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100