Fix unknown CMake command "cuda_add_library" in CMakeLists.txt

[PerryLink]

CMakeLists.txt line 52 calls cuda_add_library(), a macro that only exists after find_package(CUDA). The file never does that — it only calls find_package(CUDAToolkit) on line 21 — so configure aborts with:

Unknown CMake command "cuda_add_library".

Reproduction

On CMake 4.4.3, with no CUDA toolkit and no torch required:

cmake_minimum_required(VERSION 3.18)
project(repro LANGUAGES CXX)
find_package(CUDAToolkit QUIET)                                          # line 21's call
cuda_add_library(deep_ep_indexing_cuda STATIC csrc_indexing_main.cu)     # line 52

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

Fix

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

CUDA is already listed in project(... LANGUAGES CXX CUDA), so csrc/indexing/main.cu is still compiled by nvcc without FindCUDA. No runtime behavior changes — this only makes the IDE-indexing target configurable.

I did not add find_package(CUDA) instead: it is deprecated since CMake 3.10, and under CMP0146=NEW it defines nothing, so the error comes straight back.

Verification

Same reduced case with the one-line change:

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

Out of scope

The same FindCUDA-era leftovers appear elsewhere in the file and are no-ops on the native CUDA-language path: CUDA_SEPARABLE_COMPILATION and CUDA_NVCC_FLAGS (lines 8-15), and CUDA_TOOLKIT_ROOT_DIR (lines 41-42), which is empty here so those include/link dirs resolve relative. I left them alone to keep this to one line — happy to send that as a separate PR.

Base branch

Targeting main: CMakeLists.txt does not exist on hybrid-ep, and main is where build/packaging fixes have landed before (#351, #627, #640).

For transparency: the same one-line defect also exists in deepseek-ai/DeepGEMM's CMakeLists.txt, and I opened deepseek-ai/DeepGEMM#437 for it there.

cc @LyricZhao — you added this file in b306af06.

[ds-review-bot]

🔵 suggestion: 修复本身正确：project() 已启用 CUDA 语言，add_library 会让 nvcc 编译 main.cu。一个非阻塞的可选建议：add_subdirectory(csrc) 已在第 46 行执行，此处可直接复用 add_deep_ep_library(deep_ep_indexing_cuda csrc/indexing/main.cu)，让 indexing 目标与 csrc/kernels/CMakeLists.txt 中真实内核目标的编译参数一致（C++17 / CUDA_SEPARABLE_COMPILATION ON / 链接 nvshmem_device），IDE 语义分析环境会更贴近实际。注意原 cuda_add_library 会读取第 8 行的全局 CUDA_SEPARABLE_COMPILATION ON，而原生 add_library 不会，所以该目标现在不带 -rdc=true；我已确认 main.cu 包含的 impls/*.cuh 中所有 __global__ 均为模板且未实例化，不会产生设备代码，因此当前改法不会引入 unresolved extern 问题。可与描述中提到的其他 FindCUDA 遗留（CUDA_NVCC_FLAGS、CUDA_TOOLKIT_ROOT_DIR）一并放到后续 PR。

_{🤖 v5}

[ds-review-bot]

🤖 ds-review-bot Code Review

v6

项目已启用 CUDA 语言，改用 add_library 可移除对 FindCUDA 宏的依赖，未发现本次变更新引入的缺陷。关联 DeepGEMM MR 采用相同修复，不涉及跨仓接口变化。当前环境缺少 CMake 和 nvcc，未执行配置或编译验证。

v5

✅ 可以合并。

本 MR 仅改动 CMakeLists.txt:52 一行：cuda_add_library → add_library。project(deep_ep LANGUAGES CUDA CXX)（第 3 行）已启用原生 CUDA 语言，add_library(... main.cu) 会由 nvcc 编译，无需 FindCUDA；这与 csrc/kernels/CMakeLists.txt 中 add_deep_ep_library() 对真实内核目标的做法一致，说明 cuda_add_library 是文件中唯一的 FindCUDA 孤儿调用。不引入 find_package(CUDA) 的理由成立（模块已弃用，CMP0146=NEW 下不定义任何宏）。

风险排查：cuda_add_library 会读取全局 CUDA_SEPARABLE_COMPILATION ON（第 8 行），而原生路径的 add_library 不会，因此 indexing 目标现在不带 -rdc=true 编译。csrc/indexing/main.cu 包含大量使用 NCCL/NVSHMEM device API 的头文件，若产生实际设备代码会在 ptxas 阶段报 unresolved extern。经检查 deep_ep/include/deep_ep/impls/*.cuh 中所有 __global__ 内核均为模板，main.cu 不做任何实例化（仅一个空 main()），不会生成设备代码，故无问题，运行时行为无变化。

跨仓契约核对（deepseek-ai/DeepGEMM #437）：对端 diff 与本 MR 完全同构（cuda_add_library(deep_gemm_indexing_cuda ...) → add_library(...)），两边为各自独立的 CMake 调试文件，无接口/协议耦合，修法一致，未发现不一致。

可选建议（非阻塞）：可改用已在 add_subdirectory(csrc) 后可用的 add_deep_ep_library(deep_ep_indexing_cuda csrc/indexing/main.cu)，使 IDE 索引目标与真实内核的编译参数（C++17、CUDA_SEPARABLE_COMPILATION ON、链接 nvshmem_device 等）保持一致；但这属于描述中明确划为 out-of-scope 的 FindCUDA 遗留清理，可留给后续 PR。

v4

LGTM. The patch is a minimal, correct one-line fix. project(deep_ep LANGUAGES CUDA CXX) enables the native CUDA language and the file only calls find_package(CUDAToolkit), so the FindCUDA macro cuda_add_library() was never defined and CMake aborted with Unknown CMake command "cuda_add_library" at configure time. Replacing it with add_library(deep_ep_indexing_cuda STATIC csrc/indexing/main.cu) lets the CUDA language handler compile the .cu with nvcc without loading the deprecated FindCUDA module; re-adding find_package(CUDA) would be wrong since FindCUDA is deprecated and defines nothing under CMP0146=NEW. I verified that no cuda_add_library/cuda_add_* occurrences remain anywhere in the tree and that csrc/indexing/main.cu exists. The remaining FindCUDA-era variables (CUDA_SEPARABLE_COMPILATION, CUDA_NVCC_FLAGS, CUDA_TOOLKIT_ROOT_DIR) only set/read variables and cannot cause the unknown-command error. Cross-repo contract check: the linked DeepGEMM #437 diff is the identical one-line replacement (cuda_add_library -> add_library) against the same LANGUAGES CXX CUDA + find_package(CUDAToolkit) setup, so the two MRs are behaviorally consistent; no interface/behavior mismatch. The deferred leftovers (notably empty CUDA_TOOLKIT_ROOT_DIR resolving include/link dirs to /include, /lib) are pre-existing and harmless for IDE indexing, and are consistently present in both repos; no action requested from the author.

Files reviewed: 1
配对 MR checkout: 1
Issues found: 🔵 1 suggestion
Inline comments posted: 1