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

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions