4_CUDA_Libraries: cmake -S cpp fails — CUDA language not enabled for the subtree, so cuda_std_17 is unresolvable for 24 leaves (v13.3)
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 9.6k
- Forks
- 2.4k
- Avg merge
- 53m
- Merged PRs (30d)
- 1
Description
Summary
Configuring the C++ samples subtree directly — cmake -S cpp — fails on a clean v13.3 checkout with target_compile_features no known features for CUDA compiler "" version . for 24 of the 39 cpp/4_CUDA_Libraries/* samples. Building from the repo root (cmake -S .) works, because the root CMakeLists.txt enables the CUDA language globally; the cpp/ subtree does not, so cuda_std_17 is unresolvable there.
The README documents building "from any subdirectory of the samples repo," and cpp/ is such a subdirectory, so this is a documented build path that fails.
Possibly related to #402 (
target_compile_features no known features), but this appears to be a distinct variant: #402 is about the CXX feature table (… for CXX compiler "GNU" version 13.3.0) on the olderSamples/layout with CUDA 13.1; this is about the CUDA language not being enabled (… for CUDA compiler "" version .) on the v13.3cpp/layout, and here the repo-root build succeeds. Linking them in case maintainers want to consolidate.
Environment
| Component | Value |
|---|---|
| OS | Ubuntu 24.04.4 LTS |
| CUDA Toolkit | 13.3.r13.3 (nvcc V13.3.33) |
| GCC | 13.3.0 |
| CMake | 4.3.2 |
| cuda-samples | v13.3 (b7c5481) |
Reproduction
git clone --depth 1 --branch v13.3 https://github.com/NVIDIA/cuda-samples
cd cuda-samples
cmake -S cpp -B build-cpp -DCMAKE_CUDA_ARCHITECTURES="120"
Actual
24 errors of this form (one per affected leaf):
CMake Error at 4_CUDA_Libraries/FilterBorderControlNPP/CMakeLists.txt:34 (target_compile_features):
target_compile_features no known features for CUDA compiler
""
version .
Expected
The subtree configures, as the repo-root build does:
cmake -S . -B build -DCMAKE_CUDA_ARCHITECTURES="120" # configures fine
Root cause
cpp/CMakeLists.txt is purely a list of add_subdirectory() calls — it has no project(), no cmake_minimum_required(), and no enable_language(CUDA). So when cpp/ is the configure root, nothing enables the CUDA language for the subtree.
The affected leaves then declare a CXX-only project and immediately request a CUDA feature:
# cpp/4_CUDA_Libraries/simpleCUBLAS/CMakeLists.txt
project(simpleCUBLAS LANGUAGES CXX)
...
target_compile_features(simpleCUBLAS PRIVATE cxx_std_17 cuda_std_17)
With no CUDA language enabled above them and only CXX in their own project(), cuda_std_17 has no known feature set — hence no known features for CUDA compiler "" version . (empty compiler name/version = the CUDA language was never enabled).
The repo-root CMakeLists.txt, by contrast, declares project(cuda-samples LANGUAGES C CXX CUDA), so CUDA is enabled globally and every leaf's cuda_std_17 resolves.
Scope
24 of 39 4_CUDA_Libraries/* leaves, including: simpleCUBLAS, simpleCUBLAS_LU, simpleCUBLASXT, batchCUBLAS, matrixMulCUBLAS, conjugateGradient, conjugateGradientPrecond, conjugateGradientUM, cuSolverDn_LinearSolver, cuSolverRf, cuSolverSp_LinearSolver, cuSolverSp_LowlevelCholesky, cuSolverSp_LowlevelQR, boxFilterNPP, cannyEdgeDetectorNPP, FilterBorderControlNPP, freeImageInteropNPP, histEqualizationNPP, watershedSegmentationNPP, nvJPEG, nvJPEG_encoder, MersenneTwisterGP11213, randomFog, jitLto.
Suggested fix (direction)
Give the cpp/ aggregator a project that enables CUDA so the subtree is configurable on its own. Verified that the following makes cmake -S cpp configure cleanly and does not regress the repo-root configure or the repo-root build of helloTile:
# top of cpp/CMakeLists.txt
cmake_minimum_required(VERSION 3.20)
project(cuda_samples_cpp LANGUAGES C CXX CUDA)
(Verified for configure + build; I didn't exercise cmake --install, so maintainers may want to confirm the bin/<arch>/<os>/<cfg> install layout is unaffected.)
A more localized alternative is to declare CUDA in each affected leaf's project(... LANGUAGES CXX CUDA) (or enable_language(CUDA)), so a single-sample configure of those leaves enables CUDA regardless of how it's reached. Maintainers are better placed to choose between the subtree-level and per-leaf fix.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with cpp/CMakeLists.txt and reproduce using cmake -S cpp -B build-cpp -DCMAKE_CUDA_ARCHITECTURES="120" on v13.3. Compare it with the repo-root CMakeLists.txt and an affected leaf such as cpp/4_CUDA_Libraries/simpleCUBLAS/CMakeLists.txt. Done means the cpp subtree configures cleanly without regressing the root configure or the helloTile build; verify the install layout if relevant.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cmake, cpp
- Domain
- build-system
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100