兩年前幫朋友收拾一個(gè)遺留項(xiàng)目第一件事是打開 Visual Studio 點(diǎn) Build結(jié)果一下午都在和“無(wú)法打開源文件”以及各種配置項(xiàng)搏斗。后來(lái)我把整個(gè)項(xiàng)目從 IDE 配置遷移到 CMake 命令行工具同樣一套源碼一條命令完成配置一條命令完成編譯換一臺(tái)電腦兩分鐘就能復(fù)現(xiàn)。從那時(shí)候起我就發(fā)現(xiàn)真正決定工程可維護(hù)性的不是用哪個(gè) IDE而是構(gòu)建流程里到底藏了多少“不寫在明面上”的東西。這篇不是 CMake 從入門到精通的百科而是圍繞“命令行工具”這一個(gè)視角把一套工程從配置、編譯、測(cè)試、安裝到錯(cuò)誤排查完整走一遍。適合剛接觸 CMake、看過(guò)不少教程卻始終沒(méi)搞懂命令行怎么用的新手也適合被 GUI 配置搞到頭大、想在 CI 或跨平臺(tái)環(huán)境里穩(wěn)定構(gòu)建的人。1. 構(gòu)建工具的第一印象為什么我不再點(diǎn) IDE 里的 Build 按鈕先說(shuō)一個(gè)我觀察到的現(xiàn)象很多新人學(xué) CMake第一步是從網(wǎng)上搜到一段cmake_minimum_required和add_executable然后打開 IDE 導(dǎo)入源碼點(diǎn)一下 Build編譯通過(guò)教程結(jié)束。等到換一臺(tái)電腦、換一個(gè)編譯器同一個(gè)工程在別人機(jī)器上死活編譯不過(guò)這時(shí)候才知道 CMake 的“配置”和“構(gòu)建”根本是兩碼事。IDE 里的 Build 按鈕方便但它把太多狀態(tài)藏起來(lái)了用的哪個(gè)編譯器、哪個(gè)生成器、緩存里存了什么、依賴庫(kù)從哪找全都不直觀。命令行工具恰恰相反它把構(gòu)建過(guò)程拆成獨(dú)立的、可命名的、可重復(fù)執(zhí)行的步驟。源碼是文本命令也是文本狀態(tài)攤在明面上出了問(wèn)題可以翻命令、翻日志、在 CI 里回放而不需要打開某個(gè) GUI 一個(gè)選項(xiàng)一個(gè)選項(xiàng)地猜。1.1 可復(fù)現(xiàn)的構(gòu)建命令行讓工程狀態(tài)攤在明面上可復(fù)現(xiàn)的意思是同一份源碼、同一條命令、同一個(gè)環(huán)境得到的結(jié)果應(yīng)該是確定的。IDE 點(diǎn)按鈕做不到這一點(diǎn)因?yàn)榘粹o背后還跟著你的鼠標(biāo)位置、當(dāng)前選中的解決方案配置、全局環(huán)境變量、甚至上一次構(gòu)建留下的緩存。我在實(shí)際項(xiàng)目里吃過(guò)這個(gè)虧。某個(gè)項(xiàng)目 README 寫著“用 Visual Studio 打開 xxx.sln 并編譯”新同事照做之后編譯失敗一排查發(fā)現(xiàn)是他的 VS 沒(méi)裝某個(gè)組件而 README 完全沒(méi)提。后來(lái)我換成命令行把配置步驟寫成cmake -S . -B build -D CMAKE_BUILD_TYPERelease構(gòu)建步驟寫成cmake --build build放到文檔里問(wèn)題再?zèng)]出現(xiàn)過(guò)。命令行工具的另一個(gè)價(jià)值是日志。GUI 構(gòu)建窗口里的日志往往是一次性的關(guān)掉就沒(méi)了命令行日志可以直接重定向到文件甚至完整保存下來(lái)。遇到“當(dāng)時(shí)能編譯過(guò)現(xiàn)在不行”的詭異問(wèn)題翻歷史日志往往立刻能找到原因。1.2 命令行工具全家桶cmake、ctest、cpack 與 cmake -E很多人以為 CMake 命令行工具就是cmake這一個(gè)程序其實(shí)準(zhǔn)確地說(shuō)CMake 提供了一整套命令行入口各自負(fù)責(zé)工程生命周期里的一段cmake配置工程、生成構(gòu)建系統(tǒng)也負(fù)責(zé)驅(qū)動(dòng)最終的構(gòu)建。ctest讀取工程里的測(cè)試定義批量執(zhí)行測(cè)試并輸出結(jié)果。cpack基于安裝規(guī)則打二進(jìn)制包生成壓縮包或安裝程序。cmake -E跨平臺(tái)執(zhí)行文件操作、環(huán)境變量操作、時(shí)間獲取等小工具適合寫自動(dòng)化腳本。cmake -P直接運(yùn)行一個(gè) CMake 腳本文件不需要任何工程結(jié)構(gòu)。這套組合的意義在于你不需要在 Windows 上寫.bat、在 Linux 上寫.sh、在 CI 里再寫一套 YAML只要學(xué)會(huì) CMake 命令行的習(xí)慣所有平臺(tái)都能統(tǒng)一處理。后面我會(huì)逐個(gè)拆開講先把“命令行工具不是 cmake 一個(gè)命令”這個(gè)觀念立住。2. 裝好 CMake 命令行環(huán)境最容易翻車的三個(gè)細(xì)節(jié)好工具也得先裝對(duì)。CMake 安裝本身不難但我在無(wú)數(shù)臺(tái)機(jī)器上見(jiàn)過(guò)因?yàn)榘惭b細(xì)節(jié)導(dǎo)致的環(huán)境混亂最常見(jiàn)的有三件事版本太老、PATH 沒(méi)配好、系統(tǒng)里同時(shí)存在多個(gè) CMake。2.1 Windows、Linux 下的安裝方式與版本選擇Windows 上最簡(jiǎn)單的方式是去官網(wǎng) cmake.org/download 下載.msi安裝器。64 位系統(tǒng)記得選windows-x86_64的包不要下成 32 位。安裝過(guò)程中有兩個(gè)選項(xiàng)必須仔細(xì)看勾選 “Add CMake to the system PATH for all users”否則你打開新終端會(huì)提示找不到 cmake。選擇安裝范圍時(shí)選 “Install for all users”避免文件被裝進(jìn)用戶臨時(shí)目錄。如果你習(xí)慣用包管理器也可以靜默安裝choco install cmake --installargs ADD_CMAKE_TO_PATHSystemLinux 上最常見(jiàn)的錯(cuò)誤是直接用apt install cmake然后發(fā)現(xiàn)版本太老。Ubuntu 20.04 自帶的 CMake 可能是 3.16老版本 Ubuntu 甚至只有 3.10而 Qt6 和很多現(xiàn)代工程要求最低 3.16于是配置階段直接報(bào)“found unsuitable version”。如果只是學(xué)習(xí)apt 裝一個(gè)能用就行如果要編 Qt6 或者用新 CMakePresets 特性建議從官方預(yù)編譯包或 Kitware 的 apt 倉(cāng)庫(kù)裝新版。手動(dòng)安裝官方預(yù)編譯包也很簡(jiǎn)單wget https://github.com/Kitware/CMake/releases/download/v3.31.5/cmake-3.31.5-linux-x86_64.tar.gz tar -xzf cmake-3.31.5-linux-x86_64.tar.gz export PATH$PWD/cmake-3.31.5-linux-x86_64/bin:$PATH版本選擇上我的建議是別追最新也別用太舊。工程里如果寫了cmake_minimum_required(VERSION 3.16)就用 3.16 以上的版本如果已經(jīng)在用 CMakePresets建議 3.23 以上。只要能通過(guò)工程的版本檢查新老版本在命令行用法上沒(méi)有本質(zhì)區(qū)別。2.2 安裝后先做環(huán)境體檢cmake --version 與 where cmake裝完第一件事不是急著建工程而是確認(rèn)命令行的“當(dāng)前狀態(tài)”。在終端里輸入cmake --version正常會(huì)看到類似這樣的輸出cmake version 3.31.5 CMake suite maintained and supported by Kitware (kitware.com/cmake).第一行版本號(hào)能對(duì)得上就說(shuō)明 PATH 里的 cmake 是可用的。如果提示cmake: command not found或者 Windows 下提示“cmake 不是內(nèi)部或外部命令”先別懷疑安裝壞了99% 是 PATH 沒(méi)生效要么重開一個(gè)終端要么手動(dòng)把 CMake 安裝目錄下的bin路徑加進(jìn)系統(tǒng) PATH。Windows 上還有一個(gè)高頻坑系統(tǒng)里存在多個(gè) CMake。比如你用 Visual Studio Installer 裝了一個(gè)又裝了 Qt 自帶的還手動(dòng)裝過(guò)官網(wǎng)版本那么在 PowerShell 里執(zhí)行where cmake會(huì)列出好幾個(gè)路徑。調(diào)用時(shí)到底用的是哪個(gè)取決于 PATH 順序。這種多版本共存最容易造成“我這個(gè)機(jī)器能編你那個(gè)機(jī)器不行”的假象。我處理這類問(wèn)題的固定步驟是先where cmake看當(dāng)前用的是哪個(gè)再?zèng)Q定卸載冗余版本還是把目標(biāo)版本調(diào)到 PATH 前面。2.3 生成器選擇Unix Makefiles、Ninja 與 Visual StudioCMake 本身不直接編譯它負(fù)責(zé)生成“構(gòu)建系統(tǒng)”真正干活的是底層工具也就是生成器。命令行工具里生成器選型是個(gè)大話題也是很多人一開始就被繞暈的地方。默認(rèn)生成器隨平臺(tái)走Linux 上是 Unix MakefilesWindows 上是 Visual Studio 系列。但這不代表默認(rèn)就是最適合的。我自己在 Linux 和 Windows 上都偏向用 Ninja原因有三個(gè)并行編譯調(diào)度更好增量構(gòu)建速度快。出錯(cuò)時(shí)輸出的信息更可讀?？缙脚_(tái)工作流一致不需要在 Makefile 和 VS 工程之間切換思維。如果你想用 Ninja安裝 Ninja 之后在配置階段指定即可cmake -S . -B build -G Ninja幾個(gè)常見(jiàn)生成器的選擇參考生成器適合場(chǎng)景產(chǎn)物Unix MakefilesLinux/macOS 通用老工程兼容好MakefileNinja跨平臺(tái)、大型工程、增量構(gòu)建、CIbuild.ninjaVisual Studio 17 2022Windows 上配合 MSVC、需要 .sln 工程.sln/.vcxprojMinGW MakefilesWindows 上只有 MinGW 工具鏈、沒(méi)有 VSMakefile一個(gè)目錄一旦用某個(gè)生成器配置過(guò)生成器的信息會(huì)寫進(jìn)CMakeCache.txt。以后在同一目錄里反復(fù)構(gòu)建沒(méi)問(wèn)題但想換生成器請(qǐng)新建一個(gè)目錄或者刪掉緩存否則就會(huì)碰到第 4 節(jié)里那個(gè)經(jīng)典報(bào)錯(cuò)。3. 主鏈路拆解configure、build、install、test 一條龍CMake 命令行的日常操作可以壓縮成幾個(gè)固定動(dòng)作配置、構(gòu)建、安裝、測(cè)試。把這幾個(gè)動(dòng)作背后的參數(shù)和邏輯搞清楚命令行基本就入門了。3.1 配置階段-S、-B 與緩存變量的真實(shí)含義配置階段的核心命令是cmake -S . -B build-S指定源碼目錄-B指定構(gòu)建目錄。為什么現(xiàn)代 CMake 強(qiáng)烈推薦這個(gè)寫法而不是老教程里的cd build cmake ..因?yàn)?S -B不依賴你當(dāng)前在哪個(gè)目錄執(zhí)行無(wú)論你站在源碼根目錄、子目錄還是完全不相干的位置它都明確知道源文件在哪、構(gòu)建產(chǎn)物放哪。這在腳本和 CI 里是剛需。配置階段干的事很重讀取頂層CMakeLists.txt檢查cmake_minimum_required執(zhí)行project()探測(cè)編譯器查找依賴庫(kù)然后把一堆變量寫入CMakeCache.txt最后生成構(gòu)建系統(tǒng)文件。這個(gè)階段最常用的是追加緩存變量cmake -S . -B build -D CMAKE_BUILD_TYPERelease cmake -S . -B build -D CMAKE_INSTALL_PREFIX/usr/local cmake -S . -B build -D CMAKE_PREFIX_PATHC:/Qt/6.5.3/msvc2019_64-D后面的東西叫緩存變量說(shuō)白了就是你想覆蓋工程默認(rèn)配置的開關(guān)。如果你之前照著網(wǎng)上教程編過(guò) OpenCV一定見(jiàn)過(guò)一長(zhǎng)串的-D CMAKE_BUILD_TYPERELEASE -D WITH_CUDAON之類的命令那些全是緩存變量。理解這一層所謂“OpenCV 編譯步驟”就不再是一篇需要死記硬背的教程而是一堆緩存變量和命令行參數(shù)的組合。這里要提一個(gè)重要區(qū)分CMAKE_BUILD_TYPE只在單配置生成器Makefiles、Ninja下有意義Visual Studio 和 Xcode 是多配置生成器Debug/Release 的選擇發(fā)生在構(gòu)建階段用--config指定。很多跨平臺(tái)工程在這上面栽過(guò)跟頭Windows 上配置時(shí)加了-D CMAKE_BUILD_TYPERelease結(jié)果用 VS 構(gòu)建時(shí)根本不生效。3.2 構(gòu)建階段為什么 --build 比直接敲 make 更靠譜配置完成之后執(zhí)行構(gòu)建的命令是cmake --build build這條命令會(huì)替你去調(diào)用底層生成器。你不需要關(guān)心背后是 make、ninja 還是 MSBuildCMake 全都翻譯好了。這也是命令行工作流里最值得養(yǎng)成習(xí)慣的一點(diǎn)盡量用cmake --build而不是直接敲make因?yàn)楹笳甙涯愕拿罱壦涝谔囟ㄉ善魃?。?gòu)建階段常用的幾個(gè)參數(shù)# 指定構(gòu)建目標(biāo)避免每次都把全部目標(biāo)編譯一遍 cmake --build build --target myapp # 指定多配置生成器的配置類型 cmake --build build --config Release # 指定并行度比直接給 make -j 更通用 cmake --build build --parallel 8還有一個(gè)被誤解很多次的問(wèn)題改了CMakeLists.txt之后到底要不要重新運(yùn)行配置答案是不用。cmake --build build執(zhí)行時(shí)如果發(fā)現(xiàn) CMake 相關(guān)文件比上次生成的時(shí)間新會(huì)自動(dòng)重新運(yùn)行配置步驟然后再繼續(xù)構(gòu)建。實(shí)際開發(fā)里你 90% 的時(shí)間只需要這一條命令它就是那個(gè)被搬到命令行的 Build 按鈕。3.3 安裝、測(cè)試與清理閉環(huán)里的“冷門”命令構(gòu)建通過(guò)之后安裝也是一條命令cmake --install build --prefix ./install--prefix可以臨時(shí)覆蓋CMAKE_INSTALL_PREFIX非常方便。但注意一點(diǎn)如果你在CMakeLists.txt里沒(méi)有寫任何install()規(guī)則這條命令執(zhí)行完是空的不會(huì)幫你把可執(zhí)行文件復(fù)制出來(lái)。很多新手以為 CMake 天然懂得該安裝哪些文件其實(shí)安裝內(nèi)容需要你在工程里顯式聲明。測(cè)試環(huán)節(jié)獨(dú)立使用 ctestctest --test-dir build --output-on-failure--test-dir指定構(gòu)建目錄--output-on-failure的意思是只有測(cè)試掛了才輸出詳細(xì)信息否則屏幕保持干凈。多配置生成器下加一個(gè)-C Release指定配置類型即可。清理構(gòu)建產(chǎn)物可以不用手刪整個(gè)目錄CMake 自帶跨平臺(tái)刪除命令cmake -E rm -rf buildcmake -E系列還包括cmake -E make_directory、cmake -E env、cmake -E time等在 Windows 和 Linux 上行為一致寫自動(dòng)化腳本時(shí)比混用 shell 命令省心得多。4. 報(bào)錯(cuò)排查實(shí)戰(zhàn)一條 CMake Error 到編譯器問(wèn)題的完整鏈路命令行工具用久了見(jiàn)報(bào)錯(cuò)比見(jiàn)成功消息還多。很多新手一看到CMake Error at ...就慌其實(shí) CMake 的報(bào)錯(cuò)信息非常有結(jié)構(gòu)只要按順序讀絕大多數(shù)問(wèn)題能在兩分鐘內(nèi)定位。4.1 先學(xué)會(huì)讀報(bào)錯(cuò)Error at、Call Stack 和真正的原因網(wǎng)上常能看到類似這樣的報(bào)錯(cuò)例如搜索熱詞里出現(xiàn)的CMake Error at /usr/share/cmake-4.2/modules/CMakeDetermineCompilerId.cmake:9 (message): ... Call Stack (most recent call first): CMakeLists.txt:3 (project)這個(gè)信息要拆開看。第一行Error at給出了出錯(cuò)位置后面緊跟的 message 才是關(guān)鍵。如果出錯(cuò)的路徑是/usr/share/cmake-* /Modules/這種系統(tǒng)模塊目錄說(shuō)明問(wèn)題大概率不是你的CMakeLists.txt寫錯(cuò)了而是 CMake 內(nèi)部某個(gè)機(jī)制失敗常見(jiàn)就是編譯器探測(cè)。接下來(lái)看Call Stack它告訴你這個(gè)錯(cuò)誤是從哪一路調(diào)用下來(lái)的。最底下的CMakeLists.txt:3 (project)是你的工程入口也就是說(shuō)project()這一步觸發(fā)了后面的系統(tǒng)模塊。看到這種結(jié)構(gòu)正確反應(yīng)不是去改項(xiàng)目里的代碼而是先檢查工具鏈本身。4.2 CMakeDetermineCompilerId 報(bào)錯(cuò)背后的編譯器探測(cè)機(jī)制CMakeDetermineCompilerId.cmake這個(gè)模塊干的事可以簡(jiǎn)化理解為CMake 在project()階段需要知道當(dāng)前編譯器是誰(shuí)于是它生成一個(gè)超級(jí)小的測(cè)試程序編譯、鏈接、運(yùn)行然后從結(jié)果里讀出編譯器 ID。這一整套探測(cè)過(guò)程并不可見(jiàn)但一旦失敗就會(huì)拋出像 4.1 那樣的報(bào)錯(cuò)。完整的排查鏈路我按自己的習(xí)慣排了五步確認(rèn)編譯器本身存在且能運(yùn)行。Linux 上執(zhí)行g(shù)cc --version或cc --versionWindows 上如果打算用 MSVC必須打開“x64 Native Tools Command Prompt”否則cl不在 PATH 里。檢查環(huán)境變量CC和CXX。有時(shí)候你之前 export 過(guò)CC/wrong/path/to/gccCMake 會(huì)乖乖用這個(gè)不存在的編譯器去探測(cè)然后報(bào)錯(cuò)。執(zhí)行echo $CC和echo $CXX有問(wèn)題就 unset。檢查CMakeCache.txt里是否殘留舊編譯器路徑。如果之前換過(guò)編譯器緩存里可能記著舊的CMAKE_C_COMPILER清理整個(gè) build 目錄最省事。創(chuàng)建一個(gè)最小工程復(fù)現(xiàn)。建一個(gè)空目錄寫一個(gè)只有project(test C)的CMakeLists.txt執(zhí)行cmake -S . -B build。如果同樣報(bào)錯(cuò)基本可以確定是系統(tǒng)工具鏈問(wèn)題和你的工程毫無(wú)關(guān)系。查看配置階段的詳細(xì)日志。配置失敗后build/CMakeFiles/下通常會(huì)生成CMakeError.log或 YAML 格式的配置日志里面有實(shí)際執(zhí)行的編譯命令以及編譯器的完整輸出這是所有排查步驟里信息量最大的地方。我遇到過(guò)最典型的一次工具鏈文件把CMAKE_C_COMPILER指向了一個(gè)不存在的路徑由于項(xiàng)目里同時(shí)用了很多自定義變量我一直盯著上面的 CMakeLists 找問(wèn)題折騰了半小時(shí)。后來(lái)建立最小工程復(fù)現(xiàn)發(fā)現(xiàn)project()都過(guò)不了才意識(shí)到是編譯器路徑錯(cuò)了。所以請(qǐng)記住報(bào)錯(cuò)出現(xiàn)在系統(tǒng)模塊路徑時(shí)默認(rèn)先懷疑編譯器和環(huán)境而不是工程代碼。4.3 緩存與生成器不一致一個(gè)能讓你折騰半天的經(jīng)典坑除了編譯器探測(cè)另一個(gè)高頻報(bào)錯(cuò)來(lái)自生成器或編譯器切換時(shí)緩存沒(méi)清理。典型場(chǎng)景是同一個(gè) build 目錄第一次用-G Ninja配置后來(lái)想換 Visual Studio直接重新執(zhí)行cmake -S . -B build -G Visual Studio 17 2022CMake 會(huì)直接拒絕因?yàn)樗l(fā)現(xiàn)緩存里已經(jīng)記了生成器是 Ninja和你現(xiàn)在傳入的不一致。解決辦法很簡(jiǎn)單刪掉 build 目錄重新配置或者干脆為不同生成器建立獨(dú)立目錄rm -rf build-ninja cmake -S . -B build-ninja -G Ninja rm -rf build-msvc cmake -S . -B build-msvc -G Visual Studio 17 2022這條原則我后來(lái)寫進(jìn)了團(tuán)隊(duì)規(guī)范一個(gè)構(gòu)建目錄只對(duì)應(yīng)一套“編譯器 生成器 配置類型”的組合。調(diào)試用build-debug發(fā)布用build-release切換工具鏈就新建目錄。這樣不僅能避免緩存沖突還能并行維護(hù)多個(gè)構(gòu)建配置命令行排查起來(lái)非常清晰。5. 命令行不止步于入門Qt 多模塊、工具鏈與 Presets會(huì)了基本命令之后真實(shí)工程里會(huì)碰到更復(fù)雜的組合Qt 項(xiàng)目怎么用命令行構(gòu)建、多模塊 CMakeLists 怎么組織、交叉編譯怎么配置、長(zhǎng)參數(shù)怎么固化。這一節(jié)我講幾個(gè)高頻場(chǎng)景。5.1 Qt 工程用命令行構(gòu)建頂層 CMakeLists 與 CMAKE_PREFIX_PATH很多 Qt 用戶習(xí)慣打開 Qt Creator點(diǎn)一下綠色三角就開始編譯等到要上 CI 或換電腦自動(dòng)化部署時(shí)就傻眼了。實(shí)際上 Qt 工程用命令行構(gòu)建非常順暢Qt6 官方從 CMake 3.16 開始提供了完整的 CMake 支持。假設(shè)項(xiàng)目結(jié)構(gòu)是MyApp/ ├── CMakeLists.txt ├── core/ │ ├── CMakeLists.txt │ └── core.cpp └── app/ ├── CMakeLists.txt ├── main.cpp └── MainWindow.cpp頂層CMakeLists.txt可以這樣寫cmake_minimum_required(VERSION 3.16) project(MyApp VERSION 1.0 LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) find_package(Qt6 REQUIRED COMPONENTS Widgets) add_subdirectory(core) add_subdirectory(app)core模塊寫成靜態(tài)庫(kù)add_library(core STATIC core.cpp) target_include_directories(core PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})app模塊負(fù)責(zé)生成可執(zhí)行文件qt_add_executable(app main.cpp MainWindow.cpp) target_link_libraries(app PRIVATE core Qt6::Widgets)配置時(shí)最關(guān)鍵的一點(diǎn)是告訴 CMake 到哪里找 Qtcmake -S . -B build \ -D CMAKE_PREFIX_PATHC:/Qt/6.5.3/msvc2019_64CMAKE_PREFIX_PATH是find_package的指路人。Qt 安裝在哪個(gè)目錄就把對(duì)應(yīng)前綴傳進(jìn)去。之后構(gòu)建、運(yùn)行都和普通工程一樣cmake --build build --target appQt 命令行構(gòu)建的好處是編譯參數(shù)、模塊依賴、跨平臺(tái)差異都被 CMake 消化掉了。你在 Windows 配一次 Qt 路徑在 Linux 上配一次剩下的構(gòu)建命令可以完全相同。5.2 交叉編譯與工具鏈文件把 Keil 工程遷移到 CMake 的思路命令行工具的另一大主場(chǎng)是交叉編譯。桌面工程有 IDE 兜底嵌入式工程往往真的只有命令行能救。交叉編譯的核心是通過(guò)CMAKE_TOOLCHAIN_FILE傳入一個(gè)工具鏈文件cmake -S . -B build-arm \ -D CMAKE_TOOLCHAIN_FILEarm-gcc-toolchain.cmake \ -D CMAKE_BUILD_TYPERelease工具鏈文件內(nèi)容類似set(CMAKE_SYSTEM_NAME Generic) set(CMAKE_SYSTEM_PROCESSOR arm) set(CMAKE_C_COMPILER arm-none-eabi-gcc) set(CMAKE_CXX_COMPILER arm-none-eabi-g) set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)網(wǎng)上經(jīng)常有人問(wèn)“如何將 Keil 工程變成 CMake”我的建議是不要指望一鍵轉(zhuǎn)換而是把它當(dāng)成一次構(gòu)建系統(tǒng)梳理把 Keil 工程里的源文件列表、宏定義、頭文件搜索路徑、芯片型號(hào)整理出來(lái)再在 CMakeLists 和工具鏈文件里逐項(xiàng)描述。Keil 的 ARMCC 編譯器也能塞進(jìn)CMAKE_C_COMPILER但更多人選擇換用 GCC 工具鏈因?yàn)樾袨楦该鳌⒏菀捉尤?CI。第三方包管理器同樣依賴命令行參數(shù)。比如用 vcpkg 管理依賴時(shí)常見(jiàn)配置是cmake -S . -B build \ -D CMAKE_TOOLCHAIN_FILEC:/vcpkg/scripts/buildsystems/vcpkg.cmake可以看到命令行能力一旦掌握桌面包管理、交叉編譯、嵌入式工具鏈背后的套路是同一個(gè)清晰的源碼目錄 構(gòu)建目錄 明確的變量剩下的交給 CMake。5.3 CMakePresets.json把長(zhǎng)參數(shù)固化進(jìn)工程命令行好用但命令太長(zhǎng)就不好維護(hù)了。如果每次配置都要敲一長(zhǎng)串-D不僅容易敲錯(cuò)團(tuán)隊(duì)協(xié)作時(shí)也很難保證每個(gè)人都用相同參數(shù)。這時(shí)候就該用CMakePresets.json。這個(gè)文件放在源碼根目錄將配置、構(gòu)建、測(cè)試參數(shù)固化下來(lái)。一個(gè)帶 Ninja 和 Qt 路徑的示例{ version: 6, configurePresets: [ { name: ninja-release, generator: Ninja, binaryDir: ${sourceDir}/build/release, cacheVariables: { CMAKE_BUILD_TYPE: Release, CMAKE_PREFIX_PATH: C:/Qt/6.5.3/msvc2019_64 } } ], buildPresets: [ { name: ninja-release, configurePreset: ninja-release } ], testPresets: [ { name: ninja-release, configurePreset: ninja-release, output: { outputOnFailure: true } } ] }有了預(yù)設(shè)之后所有成員執(zhí)行一樣的三條命令cmake --list-presets cmake --preset ninja-release cmake --build --preset ninja-release ctest --preset ninja-release我再也不會(huì)在文檔里寫“請(qǐng)手動(dòng)配置 CMAKE_BUILD_TYPE 和 CMAKE_PREFIX_PATH”這種讓人犯迷糊的步驟了。參數(shù)有默認(rèn)值、有命名、有版本管理這才符合命令行工具該有的工程化姿態(tài)。6. 高頻命令速查與我的幾條使用原則最后把日常最常用的命令整理成一張表方便你貼在終端旁邊。這些命令覆蓋了一個(gè) CMake 工程從零到測(cè)試通過(guò)的大多數(shù)場(chǎng)景。6.1 一張速查表覆蓋大部分日常需求場(chǎng)景命令首次配置默認(rèn)生成器cmake -S . -B build指定生成器和構(gòu)建類型cmake -S . -B build -G Ninja -D CMAKE_BUILD_TYPERelease指定第三方依賴路徑cmake -S . -B build -D CMAKE_PREFIX_PATHC:/Qt/6.5.3/msvc2019_64構(gòu)建全部目標(biāo)cmake --build build只構(gòu)建指定目標(biāo)cmake --build build --target app多配置生成器選擇類型cmake --build build --config Release安裝到指定前綴cmake --install build --prefix ./install執(zhí)行測(cè)試ctest --test-dir build --output-on-failure清理構(gòu)建目錄cmake -E rm -rf build直接運(yùn)行 CMake 腳本cmake -P script.cmake查看當(dāng)前環(huán)境支持哪些生成器cmake --help這張表里沒(méi)有特別高深的東西但每一條都是我實(shí)際用了很久才形成的習(xí)慣。cmake --build和cmake --install這類命令表面看只是多敲幾個(gè)字母實(shí)際上它們讓工程構(gòu)建擺脫了具體生成器的綁定換環(huán)境、換 CI 都只需要同一套心智模型。6.2 我對(duì)命令行構(gòu)建的三點(diǎn)堅(jiān)持長(zhǎng)期用命令行工具跑工程之后我給自己定了三條原則也算是給剛?cè)肟拥呐笥训慕ㄗh。第一永遠(yuǎn)使用-S和-B顯式指定目錄不要依賴當(dāng)前工作目錄。這條能避免大量“為什么我在這執(zhí)行可以到別處就不行”的問(wèn)題。第二一個(gè)構(gòu)建目錄只維護(hù)一套編譯器、生成器和配置類型。要換配置就新建目錄不要反復(fù)復(fù)用同一個(gè) build 目錄緩存陷阱是最不值得浪費(fèi)時(shí)間的坑。第三把重復(fù)出現(xiàn)的長(zhǎng)參數(shù)升級(jí)成CMakePresets.json。命令行工具的價(jià)值在于確定性和可重復(fù)性長(zhǎng)命令靠記憶就是不確定性的來(lái)源。再補(bǔ)充一個(gè)題外話Windows 生態(tài)里還有不少命令行小工具和 CMake 的理念很像比如管理驅(qū)動(dòng)倉(cāng)庫(kù)的 DriverStore Explorer它同樣提供命令行模式讓“清理過(guò)期驅(qū)動(dòng)”這種重復(fù)操作可以被腳本固化。工具可以完全不同背后的思路是一致的能把人工重復(fù)操作變成命令就值得變成命令。我在實(shí)際項(xiàng)目里體會(huì)最深的一點(diǎn)是命令行工具不是 Geek 的炫耀而是給工程注入確定性。以前我用 IDE 點(diǎn) Build看著進(jìn)度條走完就安心了現(xiàn)在我更愿意在終端里看到一行行日志流過(guò)因?yàn)樗嬖V我每一步都在按預(yù)期發(fā)生。希望你也能早點(diǎn)體會(huì)到這種安全感。