Skip to content

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) #438

Description

@yashashav-dk

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions