[BUG]: Issues from mixing CCCL CMake package with legacy Thrust/CUB/libcudacxx packages.
- Dominant language
- C++
- Stars
- 2.5k
- Forks
- 486
- Avg merge
- 2d 6h
- Merged PRs (30d)
- 295
Description
### Is this a duplicate?
- [x] I confirmed there appear to be no [duplicate issues](https://github.com/NVIDIA/cccl/issues) for this bug and that I agree to the [Code of Conduct](CODE_OF_CONDUCT.md)
### Type of Bug
Something else
### Component
Infrastructure
### Describe the bug
A MatX user recently ran into an issue where a component of their build was using the legacy `find_package(Thrust CONFIG)` directly, while MatX uses rapids-cmake to pull in CCCL with `find_package(CCCL CONFIG)`.
In this case, the `find_package(Thrust)` + `thrust_create_target(...)` calls occurred first, and located the CMake packages shipped with the system-installed CTK. Then MatX was added, which ultimately performs a CPM fetch of CCCL. The version of CCCL fetched by MatX (3.0.0) differed from the version installed with the system CTK (3.0.1).
When `find_package(CCCL)` goes to create its default `CCCL::Thrust` target, it used the `thrust-config.cmake` from the `cccl-config.cmake`'s sibling directory, which detected the previously found `CUB`, and flagged the version mismatch:
```
CMake Error at /opt/foss/lib64/rapids/cmake/thrust/thrust-config.cmake:253 (message):
The version of CUB found by CMake is not compatible with this release of
Thrust. CUB is now included in the CUDA Toolkit, so you no longer need to
use your own checkout of CUB. Pass IGNORE_CUB_VERSION_CHECK to
thrust_create_target to ignore. (CUB 3.0.1.0, Thrust 3.0.0.0).
```
This MatX bug contains more details: https://github.com/NVIDIA/MatX/issues/1074
### How to Reproduce
This should be reproducible by mocking up a project that:
1. Has two versions CCCL available.
2. Sets `CMAKE_PREFIX_PATH` as appropriate to locate one of the CCCL installations.
3. Calls `find_package(Thrust CONFIG REQUIRED)`
4. Updates `CMAKE_PREFIX_PATH` to prefer the other CCCL installation.
5. Calls `find_package(CCCL CONFIG REQUIRED)`
### Expected behavior
Unclear at the moment. Perhaps the `find_package(Thrust CONFIG)` call should also bring in the `CCCL` config, so that the later `find_package(CCCL CONFIG)` call will reuse the first installation.
Ideally, all consumers should switch to using the `CCCL` package and migrate away from the legacy configs. Alternatively, the top level project may use `find_package(CCCL CONFIG)` prior to including either dependency, as this will setup the package cache for CCCL, thrust, cub, and libcudacxx consistently.
### Reproduction link
_No response_
### Operating System
_No response_
### nvidia-smi output
_No response_
### NVCC version
_No response_
Contributor guide
Assessment
This issue has not been assessed yet.