Fix unknown CMake command "cuda_add_library" in CMakeLists.txt

[PerryLink]

CMakeLists.txt cannot configure: line 32 (nv_dev) / line 34 (main) calls cuda_add_library(), which is a macro from the deprecated FindCUDA module — but the file never loads that module; it only calls find_package(CUDAToolkit) on line 16. CMake aborts with:

Unknown CMake command "cuda_add_library".

That is fatal at configure time, so the CLion indexing support this file was added for has never worked — cuda_add_library is present in the file as far back as 5bda2724 ("Add CMake support for CLion indexing"), and find_package(CUDA) appears in no revision of it.

Reproduction

On CMake 4.4.3 a reduced case is enough — no CUDA toolkit and no torch required:

cmake_minimum_required(VERSION 3.18)
project(repro LANGUAGES CXX)
find_package(CUDAToolkit QUIET)   # line 16's call; does not define cuda_add_library
cuda_add_library(t STATIC repro.cpp)

CMake Error at CMakeLists.txt:4 (cuda_add_library):
  Unknown CMake command "cuda_add_library".

Root cause

FindCUDA defines the command only after find_package(CUDA), which appears in no revision of this file:

after find_package(CUDAToolkit): cuda_add_library is NOT DEFINED
after find_package(CUDA):        cuda_add_library IS DEFINED

The rest of the file is already on the modern path (project(... LANGUAGES CXX CUDA) line 3, CMAKE_CUDA_STANDARD line 22, find_package(CUDAToolkit) line 16), so FindCUDA is simply never pulled in.

Fix

-cuda_add_library(deep_gemm_indexing_cuda STATIC csrc/indexing/main.cu)
+add_library(deep_gemm_indexing_cuda STATIC csrc/indexing/main.cu)

Plain add_library() is the right form: CUDA is already listed in project(... LANGUAGES ...), so the .cu source still goes through nvcc without FindCUDA.

I deliberately did not add find_package(CUDA). FindCUDA has been deprecated since CMake 3.10, and with CMP0146 set to NEW (or once cmake_minimum_required reaches 3.27) find_package(CUDA) defines nothing and the error comes straight back:

after find_package(CUDA), CMP0146=NEW: cuda_add_library is NOT DEFINED

It would also contradict the CUDAToolkit usage on line 16.

Verification

Same reduced case with the one-line change:

-- Configuring done (6.1s)
-- Generating done (0.2s)

Note

Lines 7-10 (CUDA_SEPARABLE_COMPILATION, CUDA_NVCC_FLAGS) are FindCUDA variables too and are currently no-ops for the same reason. I left them out to keep this to one line — happy to send that as a separate PR if you want it.

Base branch

Targeting main (the default branch). nv_dev carries the same broken line but is 108 commits ahead of main, so this one-line change was rebased onto main rather than moved across; the identical change applies to nv_dev if you would rather take it there.

[ds-review-bot]

🔵 suggestion: Non-blocking follow-up (out of scope for this MR, as noted in the description): CUDA_SEPARABLE_COMPILATION and CUDA_NVCC_FLAGS (lines 7-10) are FindCUDA variables and are no-ops on the native CUDA language path. Modern equivalents: set_target_properties(deep_gemm_indexing_cuda PROPERTIES CUDA_SEPARABLE_COMPILATION ON) and target_compile_options(deep_gemm_indexing_cuda PRIVATE $<$<COMPILE_LANGUAGE:CUDA>:-DENABLE_FAST_DEBUG -O3 --ptxas-options=--verbose,--register-usage-level=10,--warn-on-local-memory-usage>) (or CMAKE_CUDA_FLAGS).

_{🤖 v5}

[ds-review-bot]

🔵 suggestion: Non-blocking follow-up: CUDA_TOOLKIT_ROOT_DIR (lines 24-25) is also a FindCUDA variable and will be empty here, so the cccl include dir and lib64/lib64/stubs link dirs resolve to relative paths. find_package(CUDAToolkit) provides CUDAToolkit_INCLUDE_DIRS, CUDAToolkit_LIBRARY_DIR, and CUDAToolkit_LIBRARY_ROOT instead. Suggest handling together with the lines 7-10 cleanup in a separate PR.

_{🤖 v5}

[ds-review-bot]

🔵 suggestion: Not blocking for this MR, but CUDA_SEPARABLE_COMPILATION (line 7) and CUDA_NVCC_FLAGS (lines 8-10) are also FindCUDA-era variables and remain no-ops for the same reason the original cuda_add_library() call failed. Consider a follow-up PR replacing them with the modern equivalents: the CUDA_SEPARABLE_COMPILATION target property and target_compile_options(... $<$<COMPILE_LANGUAGE:CUDA>:...>) for the nvcc flags.

_{🤖 v4}

[ds-review-bot]

🤖 ds-review-bot Code Review

v6

项目已启用 CUDA 语言，使用原生 add_library 创建包含 .cu 文件的静态库是正确做法，无需依赖旧版 FindCUDA 宏。未发现本次变更新增的问题；当前环境未安装 CMake，未执行配置验证。

v5

This MR replaces cuda_add_library() with add_library() in CMakeLists.txt (line 32). The change is correct and minimal: cuda_add_library is a macro from the deprecated FindCUDA module, which this file never loads (it only calls find_package(CUDAToolkit)), so configure has always failed with Unknown CMake command "cuda_add_library". Since project(deep_gemm LANGUAGES CXX CUDA) on line 3 already enables CUDA as a first-class language, plain add_library() compiles csrc/indexing/main.cu through nvcc without FindCUDA. Deliberately not adding find_package(CUDA) is the right call — it is deprecated since CMake 3.10, defines nothing under CMP0146=NEW, and would conflict with the existing CUDAToolkit usage. Verified via git diff 7f2a703 HEAD -- CMakeLists.txt that this is the only change, and grep confirms no other FindCUDA commands remain in project-owned CMake files (remaining hits are in vendored third-party/fmt/test/, which loads FindCUDA itself and is not part of this project's configure). Approve. Two pre-existing FindCUDA-only variable usages remain no-ops (lines 7-10 and 24-25); these are out of scope per the MR description and are flagged below as non-blocking suggestions for a follow-up PR.

v4

The change fixes a fatal configure-time error in CMakeLists.txt. The file called cuda_add_library(), a macro provided only by the deprecated FindCUDA module, while never loading that module (it only uses find_package(CUDAToolkit)). CMake therefore aborted with 'Unknown CMake command "cuda_add_library"', so the CLion indexing support this file exists for never worked. Replacing it with plain add_library() is the correct modern-CMake fix: CUDA is already enabled via project(... LANGUAGES CXX CUDA), so the .cu source is still compiled by nvcc, and the change stays consistent with the rest of the file (CMAKE_CUDA_STANDARD, CUDAToolkit). The MR is minimal, well-scoped, and does not reintroduce find_package(CUDA), which would be deprecated and would break again under CMP0146=NEW. I verified there are no remaining cuda_add_library calls in the repository, so the fix is complete and safe to merge.

Files reviewed: 1
Issues found: 🔵 3 suggestion
Inline comments posted: 3