bazel-contrib / bazel-contrib/rules_cuda

cccl_headers uses the pre-CUDA-13 include path, so <thrust/...> does not resolve on CUDA 13

Open
#489 1 comment 0 reactions 0 assignees View on GitHub
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

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.