简介CMake 3.24.0 源码压缩包面向需要在多平台、多编译器环境下管理构建流程的 C/C 开发者尤其适合在 Linux/Unix 系统上通过源码方式自行编译安装 CMake 的场景。压缩包内含 2000 个文件涵盖大量 cmake、txt、rst、c、h、cxx、cpp 等类型其中 txt 多用于说明记录cmake 为构建逻辑定义rst 为文档源文件c/cxx/cpp 为源码与测试实现同时还有丰富的测试示例、辅助脚本与配置文件整体约 9.91MB便于快速下载与离线分发。已有 425 人学习下载。资源不仅包含标准构建流程所需的 bootstrap 与 makefile 体系还覆盖 CTest、CPack、FindPackage 等关键组件及第三方依赖源码目录结构完整方便深入探究构建机制或执行定制修改是系统学习 CMake 内部组织方式的实用材料。 手里拿到cmake-3.24.0.tar.gz这个包的时候很多人的第一反应是“又得从源码编译了”第二反应才是“CMake 到底提升了什么”。说实话作为一个常年和各种构建系统打交道的开发者我反而是刻意选源码包来装的——不是喜欢折腾而是真的需要那个灵活度。CMake 到 3.24 这个版本无论是功能覆盖还是稳定性都已经非常成熟而源码编译也并没有想象中复杂。这篇东西主要写给三类人一是刚入门 CMake、想搞清楚从源码包到可用工具这件事的新手二是正被“版本太老”“编译器找不到”这类问题折磨的开发者三是想在 Windows 上顺利用 CMake 编译 C 工程的朋友。我会从源码包的选择逻辑讲起把安装、基本使用、进阶特性和高频报错一次性梳理清楚。1. 为什么是 cmake-3.24.0源码包的选择逻辑1.1 tar.gz 源码包和二进制包选哪个cmake-3.24.0.tar.gz是 CMake 官方在 GitHub 和官网同步发布的源码归档包。很多人会问既然官方提供现成的二进制包也有 apt、brew、scoop 这些包管理器可以一键装为什么还要自己编译源码答案不在于“源码更高级”而在于三个很实际的原因不受系统包管理器版本限制。Ubuntu 20.04 自带的 CMake 是 3.16.3CentOS 7 甚至只有 2.8.12。如果你想用较新的特性比如 3.16 引入的预编译头、3.20 引入的CMAKE_PROJECT_TOP_LEVEL_INCLUDES光靠apt install cmake是拿不到的。源码包则可以装上最新版本完全绕开系统源。可定制程度高。./bootstrap阶段可以指定安装路径、启停某些模块、选择构建工具Make 或 Ninja。比如你想把 CMake 装在用户目录下~/.local/cmake而不是系统目录二进制安装包用起来就没那么灵活。方便排查问题。如果以后怀疑是 CMake 本身的行为导致构建异常有一套可直接看源码的本地环境调试起来效率完全不一样。当然如果你的项目只是简单编译系统里哪个版本都无所谓直接用包管理器装也完全没问题。源码编译更适合想要掌控细节的人。1.2 3.24.0 这个版本的价值CMake 3.24.0 发布于 2022 年 8 月。在 CMake 的版本序列里它属于“功能已成型、但还没被新特性折腾坏”的典型稳定版本。到了 3.23、3.24很多重要基础设施都已经定型对 VS 2022 17.2 的完整支持Windows 上跑 MSVC 编译器非常顺target_precompile_headers()已经足够成熟跨 MSVC 和 GCC 都能用CUDA 支持进一步完善CMAKE_CUDA_ARCHITECTURES成为标准配置项cmake --install、--build这些命令行子命令用起来很顺手。还有一个容易被忽略的点3.24.0 是目前仍然支持 Windows 7 的较新版本之一。后面版本逐步抬高了系统要求如果还有人需要在老系统上工作3.24 几乎是“功能与兼容性”的平衡点。注意如果在网上搜“cmake-3.24.0.tar.gz”留意下载源。建议优先从官方路径cmake.org/files/v3.24/下载文件名对应的 SHA256 校验值在cmake.org/files/v3.24/cmake-3.24.0-SHA-256.txt可以查到下载完顺手比对一下避免拿到损坏或不完整的包。2. 从零编译安装源码包的标准流程2.1 解压与依赖准备拿到cmake-3.24.0.tar.gz之后第一步当然是解压tar -xzf cmake-3.24.0.tar.gz cd cmake-3.24.0源码编译 CMake 的依赖其实非常少一个能编译 C 的编译器GCC、Clang 或 MSVC一个构建工具Make 或 Ninja。如果是纯命令行环境下编译还需要 OpenSSL 的开发库因为 CMake 自己需要支持 HTTPS 下载libssl-dev是必需的。如果没有 OpenSSL也可以在 bootstrap 时加--no-system-ssl编译内置的 libcurl 支持但这会引入额外编译时间建议还是先装好依赖# Debian/Ubuntu sudo apt install build-essential libssl-dev # CentOS/RHEL sudo yum install gcc-c make openssl-devel环境准备做好之后检查一下系统里已有的 CMake 版本。如果是从 2.8.x 这种远古版本升级建议先which cmake看看位置避免新旧版本混淆。2.2 编译安装三步走与路径配置源码编译 CMake 本身也是用它自己的构建系统——这正是 CMake 的“自举”bootstrap机制。标准流程是./bootstrap --prefix/usr/local/cmake make -j$(nproc) sudo make install第一步./bootstrap会生成一个最小可用的本地 CMake然后用这个 CMake 来配置完整构建。这一步有几个常用参数值得记住--prefix安装路径默认是/usr/local。强烈建议设置成独立目录比如/usr/local/cmake或~/.local/cmake这样以后要卸载或切换版本直接删目录即可。--parallelN并行数可以加快 bootstrap 阶段的速度。--之后可以传递参数给 CMake 配置阶段比如-DCMAKE_BUILD_TYPERelease。make -j$(nproc)用本机核心数并行编译整个 CMake 的编译过程大概需要几分钟到十几分钟不等取决于机器性能。编译完成后的/bin/cmake就是成品此时可以直接用它验证./bin/cmake --version如果输出cmake version 3.24.0就说明构建成功了。最后make install会把文件安装到--prefix指定的路径。安装完成后为了让cmake命令直接可用需要把它加入 PATH。比如你在~/.bashrc里加一行export PATH/usr/local/cmake/bin:$PATH然后source ~/.bashrc执行cmake --version确认。提示如果系统同时存在旧的 CMake比如/usr/bin/cmake一定要让新路径排前。检查which cmake如果指向的还是旧版本就是你 PATH 的优先级没设对。另一个坑是sudo make install会把文件装进 root 的系统目录但 PATH 如果还是普通用户环境经常会遇到“明明装了却找不到”。所以我更推荐装到~/.local/cmake完全绕开权限问题。3. 上手实操CMakeLists核心写法与常用场景3.1 一个最小可用的CMake工程CMake 的核心是CMakeLists.txt。一个最小的工程只需要几行cmake_minimum_required(VERSION 3.16) project(hello_demo) add_executable(hello main.cpp)cmake_minimum_required(VERSION 3.16)这行非常关键它定义了 CMake 的最低版本要求。如果你的工程在某些机器上因为版本太老而报错往往就是这一行和实际版本不匹配导致的。稍微复杂一点的工程会涉及头文件目录和库链接cmake_minimum_required(VERSION 3.24) project(my_project LANGUAGES CXX) add_executable(my_app src/main.cpp) target_include_directories(my_app PRIVATE include) target_link_libraries(my_app PRIVATE fmt::fmt)构建时我强烈建议使用 out-of-source 的方式也就是在源码目录外建一个build目录mkdir build cd build cmake .. cmake --build . -j这样所有中间文件都隔离在build目录里想清理重建直接删目录就行不会污染源码。这也是 CMake 设计上特别提倡的方式。3.2 预编译头、MPI、CUDA的接入预编译头PCH是提升大型工程编译速度的利器。CMake 从 3.16 开始正式支持target_precompile_headers在 3.24 里已经非常成熟了target_precompile_headers(my_app PRIVATE vector string my_common.h )尖括号是系统头文件引号是工程内的头文件。使用预编译头之后那些反复包含的标准库头文件只需编译一次实测下来中型项目的编译时间能降低 30% 左右。MPI 的引入是很多科学计算项目的刚需。CMake 提供了很优雅的find_package机制find_package(MPI REQUIRED) target_link_libraries(my_mpi_app PRIVATE MPI::MPI_CXX)这三行代码会自动找到 MPI 编译器包装器、头文件和库目录并把正确的编译选项加到目标上。需要注意find_package(MPI)必须在project()里启用了LANGUAGES CXX之后使用否则会找不到MPI_CXX相关组件。CUDA 接入是另一个高频场景。要启用 CUDACMakeLists.txt 里需要明确声明project(my_cuda_app LANGUAGES CXX CUDA) set(CMAKE_CUDA_STANDARD 17) add_executable(my_cuda_app main.cu)这里最容易踩的一个坑就是热词里那个cmake error: cmake_cuda_compiler not set。这个错误通常是两种情况造成的一是project()里没有声明CUDA语言二是系统里没有安装 CUDA Toolkit也就是没有nvcc编译器。解决办法很简单确认装了 CUDA Toolkit 之后在声明语言里加上CUDA。如果 nvcc 装在了非标准路径比如/usr/local/cuda-11.8/bin/nvcc用-DCMAKE_CUDA_COMPILER/usr/local/cuda-11.8/bin/nvcc显式指定即可。4. 热词里的高频坑版本、工具链与错误排查4.1 “3.26 or higher is required”这类版本报错怎么破这是让无数人抓狂的经典报错典型格式是CMake 3.1.3...3.26 or higher is required. You are running version: 2.8.12.2问题非常直白CMakeLists.txt里写了cmake_minimum_required(VERSION 3.26)或更高的版本但你系统里的 CMake 是古董级的 2.8.12。直接硬改cmake_minimum_required往下压并不可取因为新版版本的语法和函数在老版本里根本不存在改了之后编译照样失败。最稳妥的解法就是像这篇文章开头那样用源码包装一个新版本。比如装好 3.24.0 之后这个要求 3.1.3 以上版本的项目自然就能被满足。如果你面对的项目要求的是 3.26 或更高那就需要下载对应的更新版本3.26、3.27、3.28 都可以做法和前面完全一样改一下版本号即可。还有一个既适用也容易忽略的点如果你的 CMake 是 apt 从系统源装的某些发行版会提供一个cmake之外的名字比如cmake3那是因为发行版给了特定版本一个隔离的命令名。遇到这种情况要么用完整路径调用要么直接源码装新版并覆盖 PATH。4.2 CUDA编译器、Toolchain文件与日志调试cmake_cuda_compiler not set这类报错除了前面说的语言声明和 nvcc 缺失之外还有一种“见鬼了明明声明了 CUDA 还报错”的情况project 声明工作但 CMake 在缓存里记住了上一次配置失败的结果。此时删掉build目录里的CMakeCache.txt或整个 build 目录重新配置多半就好了。Toolchain 文件是另一个容易让人迷惑的点。交叉编译时比如在 x86 上编译 ARM 程序CMake 不会自动找到目标平台的编译器需要通过以下方式指定cmake -DCMAKE_TOOLCHAIN_FILEpath/to/toolchain.cmake ..一个最小 toolchain 文件长这样set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR arm) set(CMAKE_C_COMPILER /opt/arm-linux-gnueabihf-gcc) set(CMAKE_CXX_COMPILER /opt/arm-linux-gnueabihf-g)注意toolchain 文件要在project()执行之前生效也就是说必须使用命令行参数传入不能放在源码里被project()之后加载。日志级别对应热词里的cmake loglevel。CMake 3.15 之后支持CMAKE_MESSAGE_LOG_LEVEL来控制输出信息量从ERROR到TRACE逐级递增cmake -LA .. --loglevelVERBOSE-LA可以列出所有缓存变量--loglevelVERBOSE会输出详细的配置过程诊断“某个变量为什么没生效”非常有效。这是排查构建问题的第一工具很多所谓的“奇怪问题”在 VERBOSE 级别的输出面前都会原形毕露。4.3 Windows下用CMake编译C工程Windows 下用 CMake 编译 C 工程热词里专门提到“win7 32位下载安装”。这里有个实用的版本建议如果你的机器还是 Windows 7 32 位CMake 3.24.0 是能正常运行的较新版本官方 32 位安装包cmake-3.24.0-windows-i386.exe装上就能用。更高版本3.29 往后开始要求 Windows 10老系统就只能停留在之前的版本。Windows 上 CMake 的典型工作流我推荐用 “CMake Visual Studio vcpkg” 三件套cmake -B build -G Visual Studio 17 2022 -A Win32 cmake --build build --config Release-B build指定构建目录替代旧的mkdir build cd build。-G选择生成器VS 2022、VS 2019 都有对应的字符串。-A指定架构Win32就是 32 位x64则是 64 位。如果你没有 Visual Studio也可以用 MinGW 工具链cmake -B build -G MinGW Makefiles -DCMAKE_C_COMPILERgcc -DCMAKE_CXX_COMPILERgWindows 上还有一条高频踩坑记录编译完生成的.exe双击运行提示“缺少 DLL”多半是因为没有把运行库目录加入 PATH。CMake 的CMAKE_RUNTIME_OUTPUT_DIRECTORY最好显式指定比如set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)所有运行文件会集中输出到build/bin下找文件和装包都方便得多。还有一个通过热词看到的典型问题是cmake toolchain在 Windows 上的应用。比如用 vcpkg 工具链cmake -B build -DCMAKE_TOOLCHAIN_FILEC:/vcpkg/scripts/buildsystems/vcpkg.cmake这样 vcpkg 安装的三方库就能被 CMake 自动找到省去手动设置CMAKE_PREFIX_PATH的功夫。5. 我的实际体会装了那么多次 CMake3.24.0 算是目前让我用得最舒服的一个版本。它既保留了老版本稳定的编程接口又具备了现代构建系统该有的功能预编译头、模块化工具链、CUDA 支持都足够成熟。我最推荐的组合是“源码包装新版本 独立安装目录 out-of-source 构建”这套模式无论是个人开发还是服务器部署都很省心。最后再分享一个小技巧如果你经常需要反复切换 CMake 版本不要手动改 PATH直接在~/.bashrc里维护一个软链接目录。把想用的 CMake 版本ln -s到一个~/bin目录然后 PATH 只加~/bin切换版本时只需要换软链接。这个办法帮我省了无数折腾的时间实测下来比任何版本管理工具都简单可靠。CMake 这个东西初次接触会觉得繁琐但只要熬过安装和版本那几关后面的生产力提升是非常明显的。本文还有配套的精品资源点击获取
简介CMake 3.24.0 源码压缩包面向需要在多平台、多编译器环境下管理构建流程的 C/C 开发者尤其适合在 Linux/Unix 系统上通过源码方式自行编译安装 CMake 的场景。压缩包内含 2000 个文件涵盖大量 cmake、txt、rst、c、h、cxx、cpp 等类型其中 txt 多用于说明记录cmake 为构建逻辑定义rst 为文档源文件c/cxx/cpp 为源码与测试实现同时还有丰富的测试示例、辅助脚本与配置文件整体约 9.91MB便于快速下载与离线分发。已有 425 人学习下载。资源不仅包含标准构建流程所需的 bootstrap 与 makefile 体系还覆盖 CTest、CPack、FindPackage 等关键组件及第三方依赖源码目录结构完整方便深入探究构建机制或执行定制修改是系统学习 CMake 内部组织方式的实用材料。 手里拿到cmake-3.24.0.tar.gz这个包的时候很多人的第一反应是“又得从源码编译了”第二反应才是“CMake 到底提升了什么”。说实话作为一个常年和各种构建系统打交道的开发者我反而是刻意选源码包来装的——不是喜欢折腾而是真的需要那个灵活度。CMake 到 3.24 这个版本无论是功能覆盖还是稳定性都已经非常成熟而源码编译也并没有想象中复杂。这篇东西主要写给三类人一是刚入门 CMake、想搞清楚从源码包到可用工具这件事的新手二是正被“版本太老”“编译器找不到”这类问题折磨的开发者三是想在 Windows 上顺利用 CMake 编译 C 工程的朋友。我会从源码包的选择逻辑讲起把安装、基本使用、进阶特性和高频报错一次性梳理清楚。1. 为什么是 cmake-3.24.0源码包的选择逻辑1.1 tar.gz 源码包和二进制包选哪个cmake-3.24.0.tar.gz是 CMake 官方在 GitHub 和官网同步发布的源码归档包。很多人会问既然官方提供现成的二进制包也有 apt、brew、scoop 这些包管理器可以一键装为什么还要自己编译源码答案不在于“源码更高级”而在于三个很实际的原因不受系统包管理器版本限制。Ubuntu 20.04 自带的 CMake 是 3.16.3CentOS 7 甚至只有 2.8.12。如果你想用较新的特性比如 3.16 引入的预编译头、3.20 引入的CMAKE_PROJECT_TOP_LEVEL_INCLUDES光靠apt install cmake是拿不到的。源码包则可以装上最新版本完全绕开系统源。可定制程度高。./bootstrap阶段可以指定安装路径、启停某些模块、选择构建工具Make 或 Ninja。比如你想把 CMake 装在用户目录下~/.local/cmake而不是系统目录二进制安装包用起来就没那么灵活。方便排查问题。如果以后怀疑是 CMake 本身的行为导致构建异常有一套可直接看源码的本地环境调试起来效率完全不一样。当然如果你的项目只是简单编译系统里哪个版本都无所谓直接用包管理器装也完全没问题。源码编译更适合想要掌控细节的人。1.2 3.24.0 这个版本的价值CMake 3.24.0 发布于 2022 年 8 月。在 CMake 的版本序列里它属于“功能已成型、但还没被新特性折腾坏”的典型稳定版本。到了 3.23、3.24很多重要基础设施都已经定型对 VS 2022 17.2 的完整支持Windows 上跑 MSVC 编译器非常顺target_precompile_headers()已经足够成熟跨 MSVC 和 GCC 都能用CUDA 支持进一步完善CMAKE_CUDA_ARCHITECTURES成为标准配置项cmake --install、--build这些命令行子命令用起来很顺手。还有一个容易被忽略的点3.24.0 是目前仍然支持 Windows 7 的较新版本之一。后面版本逐步抬高了系统要求如果还有人需要在老系统上工作3.24 几乎是“功能与兼容性”的平衡点。注意如果在网上搜“cmake-3.24.0.tar.gz”留意下载源。建议优先从官方路径cmake.org/files/v3.24/下载文件名对应的 SHA256 校验值在cmake.org/files/v3.24/cmake-3.24.0-SHA-256.txt可以查到下载完顺手比对一下避免拿到损坏或不完整的包。2. 从零编译安装源码包的标准流程2.1 解压与依赖准备拿到cmake-3.24.0.tar.gz之后第一步当然是解压tar -xzf cmake-3.24.0.tar.gz cd cmake-3.24.0源码编译 CMake 的依赖其实非常少一个能编译 C 的编译器GCC、Clang 或 MSVC一个构建工具Make 或 Ninja。如果是纯命令行环境下编译还需要 OpenSSL 的开发库因为 CMake 自己需要支持 HTTPS 下载libssl-dev是必需的。如果没有 OpenSSL也可以在 bootstrap 时加--no-system-ssl编译内置的 libcurl 支持但这会引入额外编译时间建议还是先装好依赖# Debian/Ubuntu sudo apt install build-essential libssl-dev # CentOS/RHEL sudo yum install gcc-c make openssl-devel环境准备做好之后检查一下系统里已有的 CMake 版本。如果是从 2.8.x 这种远古版本升级建议先which cmake看看位置避免新旧版本混淆。2.2 编译安装三步走与路径配置源码编译 CMake 本身也是用它自己的构建系统——这正是 CMake 的“自举”bootstrap机制。标准流程是./bootstrap --prefix/usr/local/cmake make -j$(nproc) sudo make install第一步./bootstrap会生成一个最小可用的本地 CMake然后用这个 CMake 来配置完整构建。这一步有几个常用参数值得记住--prefix安装路径默认是/usr/local。强烈建议设置成独立目录比如/usr/local/cmake或~/.local/cmake这样以后要卸载或切换版本直接删目录即可。--parallelN并行数可以加快 bootstrap 阶段的速度。--之后可以传递参数给 CMake 配置阶段比如-DCMAKE_BUILD_TYPERelease。make -j$(nproc)用本机核心数并行编译整个 CMake 的编译过程大概需要几分钟到十几分钟不等取决于机器性能。编译完成后的/bin/cmake就是成品此时可以直接用它验证./bin/cmake --version如果输出cmake version 3.24.0就说明构建成功了。最后make install会把文件安装到--prefix指定的路径。安装完成后为了让cmake命令直接可用需要把它加入 PATH。比如你在~/.bashrc里加一行export PATH/usr/local/cmake/bin:$PATH然后source ~/.bashrc执行cmake --version确认。提示如果系统同时存在旧的 CMake比如/usr/bin/cmake一定要让新路径排前。检查which cmake如果指向的还是旧版本就是你 PATH 的优先级没设对。另一个坑是sudo make install会把文件装进 root 的系统目录但 PATH 如果还是普通用户环境经常会遇到“明明装了却找不到”。所以我更推荐装到~/.local/cmake完全绕开权限问题。3. 上手实操CMakeLists核心写法与常用场景3.1 一个最小可用的CMake工程CMake 的核心是CMakeLists.txt。一个最小的工程只需要几行cmake_minimum_required(VERSION 3.16) project(hello_demo) add_executable(hello main.cpp)cmake_minimum_required(VERSION 3.16)这行非常关键它定义了 CMake 的最低版本要求。如果你的工程在某些机器上因为版本太老而报错往往就是这一行和实际版本不匹配导致的。稍微复杂一点的工程会涉及头文件目录和库链接cmake_minimum_required(VERSION 3.24) project(my_project LANGUAGES CXX) add_executable(my_app src/main.cpp) target_include_directories(my_app PRIVATE include) target_link_libraries(my_app PRIVATE fmt::fmt)构建时我强烈建议使用 out-of-source 的方式也就是在源码目录外建一个build目录mkdir build cd build cmake .. cmake --build . -j这样所有中间文件都隔离在build目录里想清理重建直接删目录就行不会污染源码。这也是 CMake 设计上特别提倡的方式。3.2 预编译头、MPI、CUDA的接入预编译头PCH是提升大型工程编译速度的利器。CMake 从 3.16 开始正式支持target_precompile_headers在 3.24 里已经非常成熟了target_precompile_headers(my_app PRIVATE vector string my_common.h )尖括号是系统头文件引号是工程内的头文件。使用预编译头之后那些反复包含的标准库头文件只需编译一次实测下来中型项目的编译时间能降低 30% 左右。MPI 的引入是很多科学计算项目的刚需。CMake 提供了很优雅的find_package机制find_package(MPI REQUIRED) target_link_libraries(my_mpi_app PRIVATE MPI::MPI_CXX)这三行代码会自动找到 MPI 编译器包装器、头文件和库目录并把正确的编译选项加到目标上。需要注意find_package(MPI)必须在project()里启用了LANGUAGES CXX之后使用否则会找不到MPI_CXX相关组件。CUDA 接入是另一个高频场景。要启用 CUDACMakeLists.txt 里需要明确声明project(my_cuda_app LANGUAGES CXX CUDA) set(CMAKE_CUDA_STANDARD 17) add_executable(my_cuda_app main.cu)这里最容易踩的一个坑就是热词里那个cmake error: cmake_cuda_compiler not set。这个错误通常是两种情况造成的一是project()里没有声明CUDA语言二是系统里没有安装 CUDA Toolkit也就是没有nvcc编译器。解决办法很简单确认装了 CUDA Toolkit 之后在声明语言里加上CUDA。如果 nvcc 装在了非标准路径比如/usr/local/cuda-11.8/bin/nvcc用-DCMAKE_CUDA_COMPILER/usr/local/cuda-11.8/bin/nvcc显式指定即可。4. 热词里的高频坑版本、工具链与错误排查4.1 “3.26 or higher is required”这类版本报错怎么破这是让无数人抓狂的经典报错典型格式是CMake 3.1.3...3.26 or higher is required. You are running version: 2.8.12.2问题非常直白CMakeLists.txt里写了cmake_minimum_required(VERSION 3.26)或更高的版本但你系统里的 CMake 是古董级的 2.8.12。直接硬改cmake_minimum_required往下压并不可取因为新版版本的语法和函数在老版本里根本不存在改了之后编译照样失败。最稳妥的解法就是像这篇文章开头那样用源码包装一个新版本。比如装好 3.24.0 之后这个要求 3.1.3 以上版本的项目自然就能被满足。如果你面对的项目要求的是 3.26 或更高那就需要下载对应的更新版本3.26、3.27、3.28 都可以做法和前面完全一样改一下版本号即可。还有一个既适用也容易忽略的点如果你的 CMake 是 apt 从系统源装的某些发行版会提供一个cmake之外的名字比如cmake3那是因为发行版给了特定版本一个隔离的命令名。遇到这种情况要么用完整路径调用要么直接源码装新版并覆盖 PATH。4.2 CUDA编译器、Toolchain文件与日志调试cmake_cuda_compiler not set这类报错除了前面说的语言声明和 nvcc 缺失之外还有一种“见鬼了明明声明了 CUDA 还报错”的情况project 声明工作但 CMake 在缓存里记住了上一次配置失败的结果。此时删掉build目录里的CMakeCache.txt或整个 build 目录重新配置多半就好了。Toolchain 文件是另一个容易让人迷惑的点。交叉编译时比如在 x86 上编译 ARM 程序CMake 不会自动找到目标平台的编译器需要通过以下方式指定cmake -DCMAKE_TOOLCHAIN_FILEpath/to/toolchain.cmake ..一个最小 toolchain 文件长这样set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR arm) set(CMAKE_C_COMPILER /opt/arm-linux-gnueabihf-gcc) set(CMAKE_CXX_COMPILER /opt/arm-linux-gnueabihf-g)注意toolchain 文件要在project()执行之前生效也就是说必须使用命令行参数传入不能放在源码里被project()之后加载。日志级别对应热词里的cmake loglevel。CMake 3.15 之后支持CMAKE_MESSAGE_LOG_LEVEL来控制输出信息量从ERROR到TRACE逐级递增cmake -LA .. --loglevelVERBOSE-LA可以列出所有缓存变量--loglevelVERBOSE会输出详细的配置过程诊断“某个变量为什么没生效”非常有效。这是排查构建问题的第一工具很多所谓的“奇怪问题”在 VERBOSE 级别的输出面前都会原形毕露。4.3 Windows下用CMake编译C工程Windows 下用 CMake 编译 C 工程热词里专门提到“win7 32位下载安装”。这里有个实用的版本建议如果你的机器还是 Windows 7 32 位CMake 3.24.0 是能正常运行的较新版本官方 32 位安装包cmake-3.24.0-windows-i386.exe装上就能用。更高版本3.29 往后开始要求 Windows 10老系统就只能停留在之前的版本。Windows 上 CMake 的典型工作流我推荐用 “CMake Visual Studio vcpkg” 三件套cmake -B build -G Visual Studio 17 2022 -A Win32 cmake --build build --config Release-B build指定构建目录替代旧的mkdir build cd build。-G选择生成器VS 2022、VS 2019 都有对应的字符串。-A指定架构Win32就是 32 位x64则是 64 位。如果你没有 Visual Studio也可以用 MinGW 工具链cmake -B build -G MinGW Makefiles -DCMAKE_C_COMPILERgcc -DCMAKE_CXX_COMPILERgWindows 上还有一条高频踩坑记录编译完生成的.exe双击运行提示“缺少 DLL”多半是因为没有把运行库目录加入 PATH。CMake 的CMAKE_RUNTIME_OUTPUT_DIRECTORY最好显式指定比如set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)所有运行文件会集中输出到build/bin下找文件和装包都方便得多。还有一个通过热词看到的典型问题是cmake toolchain在 Windows 上的应用。比如用 vcpkg 工具链cmake -B build -DCMAKE_TOOLCHAIN_FILEC:/vcpkg/scripts/buildsystems/vcpkg.cmake这样 vcpkg 安装的三方库就能被 CMake 自动找到省去手动设置CMAKE_PREFIX_PATH的功夫。5. 我的实际体会装了那么多次 CMake3.24.0 算是目前让我用得最舒服的一个版本。它既保留了老版本稳定的编程接口又具备了现代构建系统该有的功能预编译头、模块化工具链、CUDA 支持都足够成熟。我最推荐的组合是“源码包装新版本 独立安装目录 out-of-source 构建”这套模式无论是个人开发还是服务器部署都很省心。最后再分享一个小技巧如果你经常需要反复切换 CMake 版本不要手动改 PATH直接在~/.bashrc里维护一个软链接目录。把想用的 CMake 版本ln -s到一个~/bin目录然后 PATH 只加~/bin切换版本时只需要换软链接。这个办法帮我省了无数折腾的时间实测下来比任何版本管理工具都简单可靠。CMake 这个东西初次接触会觉得繁琐但只要熬过安装和版本那几关后面的生产力提升是非常明显的。本文还有配套的精品资源点击获取
