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 older Samples/ layout with CUDA 13.1; this is about the CUDA language not being enabled (… for CUDA compiler "" version .) on the v13.3 cpp/ 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.
Summary
Configuring the C++ samples subtree directly —
cmake -S cpp— fails on a clean v13.3 checkout withtarget_compile_features no known features for CUDA compiler "" version .for 24 of the 39cpp/4_CUDA_Libraries/*samples. Building from the repo root (cmake -S .) works, because the rootCMakeLists.txtenables the CUDA language globally; thecpp/subtree does not, socuda_std_17is 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.Environment
b7c5481)Reproduction
Actual
24 errors of this form (one per affected leaf):
Expected
The subtree configures, as the repo-root build does:
Root cause
cpp/CMakeLists.txtis purely a list ofadd_subdirectory()calls — it has noproject(), nocmake_minimum_required(), and noenable_language(CUDA). So whencpp/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:
With no CUDA language enabled above them and only
CXXin their ownproject(),cuda_std_17has no known feature set — henceno known features for CUDA compiler "" version .(empty compiler name/version = the CUDA language was never enabled).The repo-root
CMakeLists.txt, by contrast, declaresproject(cuda-samples LANGUAGES C CXX CUDA), so CUDA is enabled globally and every leaf'scuda_std_17resolves.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 makescmake -S cppconfigure cleanly and does not regress the repo-root configure or the repo-root build ofhelloTile:(Verified for configure + build; I didn't exercise
cmake --install, so maintainers may want to confirm thebin/<arch>/<os>/<cfg>install layout is unaffected.)A more localized alternative is to declare CUDA in each affected leaf's
project(... LANGUAGES CXX CUDA)(orenable_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.