老有人问我你在Windows上写C为什么很少开Visual Studio那个大家伙其实答案就藏在三个词里——CMake、Ninja、MSVC。这套组合我用了大概三年从最开始被CMake的报错逼到想砸电脑到现在VS Code里写代码、命令行里敲两下就能出exe整个流程已经非常丝滑。今天这篇是系列的第一篇先把为什么要这么搭环境怎么装第一个项目怎么跑起来讲透后面再聊库的引入、跨平台、打包这些进阶话题。如果你属于下面这几类人这篇内容大概率对你有用一是刚接触CMake被一大堆生成器选项Visual Studio、Unix Makefiles、Ninja弄懵的新手二是默认用VS建工程但想换到VS Code或纯命令行开发的老手三是装过Qt的MinGW版本后想再补一套MSVC工具链却不知道从哪下手的朋友。这套组合解决的核心问题很简单用轻量、可复现、跨平台的方式在Windows上编译出快而稳的C程序。1. 为什么是CMakeNinja/MSVC这套组合1.1 三个工具各司其职先把我对这三样东西的理解说清楚。很多人把CMake和编译器混在一起觉得我用CMake编译其实完全不是这么回事。CMake是构建系统生成器它本身不编译任何代码。你写一份CMakeLists.txt描述项目需要哪些源文件、用什么语言、链接什么库CMake读取这份描述后会生成一套特定构建系统需要的工程文件。这套工程文件可以是Visual Studio用的.sln可以是Ninja用的build.ninja也可以是Unix Makefiles用的Makefile。所以CMake更像一个翻译官把人类可读的项目描述翻译成构建工具能执行的任务书。Ninja是构建执行器。它拿着CMake生成的任务书真正调度编译命令、管并行、管增量编译。Ninja的设计哲学就是快没有花哨语法没有任何高级功能只干一件事以最快的速度完成文件到文件之间的依赖处理。你可以把Ninja理解成一个执行力极强的包工头图纸到位后就埋头赶工。MSVC是编译器全称Microsoft Visual C包含cl.exe编译器、link.exe链接器、Windows SDK头文件和库。它负责把C/C源码翻译成机器码。这一步才是真正编译发生的地方。一句话总结CMake定方案Ninja管调度MSVC出力气。三者配合分工非常干净。1.2 为什么选Ninja而不是Makefile或MSBuild在Windows上搞C绕不开的选择是构建系统到底用什么。其实不少人有这个疑问Makefile不也挺流行吗为什么非要Ninja。首先是Makefile在Windows上的生态很别扭。GNU Make最早是给Unix设计的Windows上的API、路径分隔符反斜杠vs正斜杠、命令行参数传递方式都跟Unix不一样。虽然CMake可以生成MinGW Makefiles或者Unix Makefiles生成器但实际跑起来常常遇到应变量、路径转义、换行符之类的问题。即使能跑也没有人拿Makefile跟Ninja比速度——比不了。然后是MSBuild的沉重问题。如果你用Visual Studio创建.vcxproj工程那构建系统就是MSBuild。它本身不慢但有两个毛病第一工程文件极其啰嗦几百行XML就为了描述几个源文件第二增量编译和并行度的调优需要打开配置面板找半天对专注写代码的人非常不友好。而VS Code生态里用CMake Tools插件默认就能跟Ninja无缝配合。Ninja的好处我在实际项目里感受非常明显默认并行CPU核心数有多少就用多少不用像Makefile那样手动加-j参数。增量编译极快文件改动后只重建受影响的部分依赖关系是CMake生成时就精确算好的。语法极简build.ninja完全不需要人来写都是CMake生成的所以Ninja本身再简陋都无所谓。构建目录干净不会像VS那样生成一堆.suo、.vcxproj.user之类的辅助文件。我自己有一个体会非常深的项目大概一千多个源文件。用MSBuild全量构建要接近5分钟糊在所有CPU核心上都能听见风扇狂转切到Ninja之后全量构建大概1分多钟增量构建经常是秒级完成。这种体验差异用过一次就回不去了。1.3 MSVC和MinGW到底有什么区别这个标题本身就是热搜词说明很多人卡在这。我尽量用最直白的方式讲清楚。MSVC是微软自家的编译器闭源跟Windows SDK深度绑定。它处理Windows API、COM组件、DirectX这些东西时最顺手调试器用的是CDB实际上VS里的调试引擎是Windows Debugger也支持最新的微软标准库实现。MinGW是GCC在Windows上的移植全称Minimalist GNU for Windows。它提供gcc/g编译器用的是GNU工具链和开源的libstdc标准库。MinGW-w64这个分支支持64位目标是目前大多数人在Windows上用的MinGW版本。两者的核心差异可以列个表对比维度MSVCMinGW编译器cl.exe微软闭源gcc/gGNU开源标准库MSVC STLlibstdc调试器配合VS/CDB配合GDBWindows API支持原生最佳通过win32接口适配Qt官方包提供MSVC版预编译包提供MinGW版预编译包跨平台代码移植注意MSVC对C标准逐步追赶对GCC扩展兼容更好实际使用中怎么选我的经验是纯Windows场景优先MSVC。比如你要写Windows服务、调用COM接口、用微软自家的工具链做性能分析MSVC是天选。但是如果你想从Linux搬一份用GCC特定扩展的代码过来或者你手头有依赖GNU生态的库比如某些科学计算库编译脚本写死了gcc那就用MinGW。再有就是Qt项目Qt官方官方下载页明确区分MSVC和MinGW两种预编译包你装了MinGW版Qt就别想用MSVC编译器去编译它反之亦然。这个坑后面我会细说。2. 环境准备三件套的安装与验证2.1 CMake的下载安装Installer和ZIP版选哪个CMake官网cmake.org可以下载下载页会给出源码和各个平台的安装包。Windows平台上两种主流方式。第一种是Windows x64 Installer双击运行安装过程中有一个Add CMake to system PATH for all users之类的选项建议勾上。如果忘了勾也可以在装完之后手动把安装目录通常是C:\Program Files\CMake\bin加到系统环境变量PATH里。注意一点改完PATH之后已经开着的终端不会自动生效必须新开一个窗口。新手最容易在这卡住装完了去旧终端敲cmake --version提示找不到命令就以为没装上于是又装一遍。第二种是ZIP版解压到某个目录后把bin目录手动加进PATH。这种方式的好处是绿色、不写注册表、方便备份。如果你公司电脑没权限装软件ZIP版是救命的。其实还有一种方式Windows上装了一些包管理器的话比如winget、choco、scoop也能装CMake。我个人不太推荐用包管理器装CMake因为CMake版本更新很快包管理器的仓库常有滞后而CMake对旧版本项目可能有兼容性问题。直接官网下载最新Installer最稳。装完验证很简单cmake --version正常情况下会输出类似cmake version 4.2.0 CMake suite maintained and supported by Kitware (kitware.com/cmake).看到版本号就说明CMake就绪了。注意我这里说的是4.2.0这种新版本不同版本号不影响使用主要看最低版本要求别卡着项目就行。2.2 Ninja的安装这步经常被忽略Ninja的安装方式很多我按推荐程度排序。方式一从GitHub Release页下载。Ninja官方仓库github.com/ninja-build/ninja的Releases页面提供Windows版本的zip包解压后把ninja.exe放进一个目录然后把目录加入PATH。这是最原始也最靠谱的方式。方式二通过Python的pip安装。如果你机器上已经有Pythonpip install ninja就能直接装上命令还能直接用。pypi上的ninja包其实是一个预编译的二进制wheel包本质就是把ninja.exe放到Python的Scripts目录里。这个方式的好处是省去手动下zip和配PATH的步骤装的时候就自动处理了。方式三通过包管理器安装。choco install ninja或scoop install ninja也都可以原理跟pip类似。区别只是哪个包管理器里源新不新。还有一个很多人不知道的点Visual Studio的Build Tools里其实自带Ninja但默认不会把它加到PATH。这是CMake找不到构建程序的一个常见根源。所以即使在Visual Studio装好了之后也建议单独确认一下ninja --version能不能跑通。验证命令ninja --version输出1.11.1或类似版本号即可。提示Ninja对环境变量的依赖很小程序本体就一个exe。只要不删配置一次就能用很久。我习惯把下载的绿色工具统一放C:\tools这类目录然后把C:\tools整体加进PATH后续工具都丢进去清爽好维护。2.3 MSVC编译工具链不用装一整个Visual Studio这是很多人不敢碰MSVC的原因——觉得我是不是必须先装巨大的VS Code不是。微软提供了独立的Build Tools for Visual Studio体积比完整IDE小不少可以只装C需要的组件。下载入口微软官网搜Visual Studio Build Tools会得到一个vs_buildtools.exe的引导安装器。双击后在工作负载页勾选**使用C的桌面开发**英文是Desktop development with C然后点安装就行。它会自动装好MSVC编译器、Windows SDK、CMake工具等一堆东西。这里顺便回应一个热搜词我需要利用vs_buildtools.exe离线安装msvc。离线安装的场景通常是内网机器。做法是在有网的机器上用vs_buildtools.exe --layout C:\offline\vs2019buildtools --add Microsoft.VisualStudio.Workload.VCTools --includeRecommended先下载好完整的离线包再把整个目录拷到目标机器在目标机器上执行vs_buildtools.exe --layout C:\offline\vs2019buildtools --add Microsoft.VisualStudio.Workload.VCTools --includeRecommended或者直接运行离线目录里的安装器。这是一套繁琐但很实用的流程详细的内网离线安装文档微软官方有这里不展开。装完之后开始菜单会多几个开发人员命令行快捷方式。最常用的是x64 Native Tools Command Prompt。点开它输入cl如果输出一大段使用帮助而不是不是内部或外部命令说明编译环境OK。MSVC工具链的关键点是cl.exe本身不在系统PATH里必须通过vcvars64.bat脚本加载环境变量。微软做的开发人员命令行其实就是帮你执行了这个脚本。所以后续我们跑CMake时全程都要在这个x64 Native Tools Command Prompt里操作否则CMake找不到编译器。2.4 三件套就绪的最终验证方式我装机都会跑一遍这套体检命令cmake --version ninja --version cl三个都正常输出就说明环境齐了。如果cl报错确认两个事情一是否用的是x64 Native Tools Command Prompt而不是普通cmd二是否真的装过使用C的桌面开发工作负载光装Build Tools本体不勾组件是没用的。3. 从零构建第一个CMake项目3.1 先写一个能跑的CMakeLists.txt假设在D:\demo目录下新建项目结构如下demo/ CMakeLists.txt main.cppmain.cpp随便写点东西#include iostream int main() { std::cout Hello, CMake Ninja MSVC! std::endl; return 0; }CMakeLists.txt是最小可用的三行cmake_minimum_required(VERSION 3.20) project(HelloDemo CXX) add_executable(hello main.cpp)逐行解释一下cmake_minimum_required(VERSION 3.20)声明CMake最低版本。新项目建议放3.20以上虽然CMake现在到4.x了但为了兼容没什么必要追最新。我习惯写3.20够用且宽松。project(HelloDemo CXX)定义项目名和语言。CXX表示C语言CMake会根据这个去探测C编译器。add_executable(hello main.cpp)告诉CMake要生成一个名为hello的可执行文件源文件是main.cpp。这段描述就是CMake的设计图纸。后面CMake会根据工具链生成Ninja的任务清单。3.2 命令行完整走一遍构建流程打开x64 Native Tools Command Prompt切到D:\demo目录执行cmake -S . -B build -G Ninja解释一下参数-S .指定源码目录为当前目录.表示当前路径。-B build指定构建目录为build。所有CMake生成的中间文件、Ninja任务文件、最终产物都会进这个目录。-G Ninja指定生成器为Ninja这是关键。执行成功会输出类似-- The CXX compiler identification is MSVC 19.44.34102 -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working CXX compiler: .../cl.exe -- Check for working CXX compiler: .../cl.exe - done -- Configuring done -- Generating done -- Build files have been written to: D:/demo/build看到Build files have been written to就是配置成功。这一步CMake实际上干了三件事探测编译器确认是MSVC的cl.exe、检测ABI信息编译器版本、架构、生成Ninja的build.ninja文件。然后构建cmake --build build这条命令会把build目录里的Ninja构建任务跑起来等价于在build目录里执行ninja命令。输出会显示编译main.cpp、链接的完整过程[1/2] Building CXX object CMakeFiles/hello.dir/main.cpp.obj [2/2] Linking CXX executable hello.exe注意[1/2]、[2/2]这种进度记号正是Ninja任务调度器在报告一共2个任务现在做到第几个。然后到build目录下找hello.exe直接运行.\build\hello.exe看到Hello, CMake Ninja MSVC!就完成了。注意不要在build目录外直接跑ninja要跑就进build目录再跑或者像我一样用cmake --build显式指定构建目录。Ninja默认读取当前目录下的build.ninja路径错了会产生诡异的错误。3.3 用CMake GUI看懂配置过程命令行对新手有点抽象这时候CMake GUI能帮上忙。CMake安装好后开始菜单里有个CMake GUI。打开后Where is the source code填D:/demoWhere to build the binaries填D:/demo/build点击Configure在弹出的窗口里选择生成器。选什么取决于你的环境如果你是在x64 Native Tools Command Prompt里打开的GUI下拉框里会出现NinjaVisual Studio 17 2022等选项选Ninja旁边编译器保持默认让它自动找。第一次Configure会问你编译器是否就绪一路确认。跑完之后界面会出现一堆红色的配置项缓存变量不用管再点Generate。之后命令行方式生成的build目录和GU I方式一样可以继续用cmake --build build来构建。我个人的看法是GUI适合学习阶段看配置选项全貌很方便熟练之后请回到命令行。因为命令行参数是可记录的可以复制到脚本、CI流程里而GUI的每次点击操作无法复现。我在实际项目里GUI只用来临时查看某个缓存变量的取值正经构建从来都是命令行。3.4 构建产物的组织逻辑build目录是怎么运作的很多人第一次看到build目录里一堆文件会懵CMakeCache.txt、CMakeFiles/、build.ninja、CMakeFiles/hello.dir/……不用紧张我们只需要认识两个关键点。第一CMake是缓存驱动的。CMakeCache.txt记录了上一次配置的所有变量值比如编译器路径、生成器类型、各种开关。你修改CMakeLists.txt里的option()开关后下一次构建CMake会自动检测变化并重新配置但如果你改了系统环境变量之类的外部因素有时需要手动删掉build目录重新配置否则结果不对。我在改工具链或者改架构比如x86换成x64时几乎总是直接把build目录删了重来干净利落。第二产物永远在构建目录里不会污染源码目录。你在D:\demo里看不到任何编译中间文件源码目录始终保持干净。这是CMake推荐的out-of-source构建模式也是为什么我们建议所有现代项目都这么做。有些老项目喜欢in-source构建直接在源码目录生成Makefile和.o文件那会把源码目录弄得很脏CMake已经在重复警告这种用法了。4. VS Code里的现代姿势CMake Tools插件4.1 装插件和选Kit命令行用熟了再回VS Code就是一个字爽。安装CMake Tools之前先装微软官方的C/C扩展然后搜CMake Tools作者是Microsoft。装完之后左侧活动栏会出现一个CMake图标底部状态栏也会出现相关的按钮。打开项目目录即包含CMakeLists.txt的目录VS Code会自动识别。此时按CtrlShiftP打开命令面板输入CMake: Select a Kit选择Visual Studio那套编译器方案。它的显示一般是类似Visual Studio Build Tools 2022 Release - amd64注意Kit列表里可能有amd64、x86、arm64等不同架构日常开发选**amd64x64**即可。选Kit这一步的本质就是让CMake Tools插件知道我要用哪个编译器。插件会在后台帮你跑cmake的configure步骤并默认使用Ninja生成器。4.2 底部状态栏的configure按钮到底怎么回事这个热搜词问的是vscode安装cmake tools底部状态栏应该有configure按钮吗。答案是应该会显示一组按钮但configure通常不是直接写Configure。新版CMake Tools的状态栏显示的是Kit选择器、Build按钮或者Build文字属性、Run按钮等。某些版本会显示Configure文字某些版本只在项目还没配置好时提示。如果底部没有相关按钮排查顺序是确认装的是CMake Tools而不是只有cmake扩展。确认当前打开的就是包含CMakeLists.txt的文件夹根目录且VS Code信任了该文件夹。用命令面板手动执行一次CMake: Configure成功后状态栏就会出现按钮。确认插件设置里cmake.configureOnOpen没有被关闭。我在实际使用时基本不看状态栏记住几个快捷键更快F7构建。CtrlF5运行当前目标。F5启动调试需要launch.json配置后续会讲。4.3 让VS Code真正调试起MSVC程序命令行构建之后能跑通只是第一步调试是日常开发更重要的环节。VS Code默认情况下F5需要一份launch.json。操作流程是在VS Code里点运行和调试侧边栏创建launch.json。选择环境C (Windows)。此时VS Code会生成一份配置。关键字段是program要指向exe的绝对路径例如{ version: 0.2.0, configurations: [ { name: C Launch (Windows), type: cppvsdbg, request: launch, program: ${workspaceFolder}/build/hello.exe, args: [], stopAtEntry: false, cwd: ${workspaceFolder}, environment: [], console: integratedTerminal } ] }type用cppvsdbg意思是使用Visual Studio的调试引擎CDB它跟MSVC编译器配合最佳。如果用MinGWtype应该改成cppdbg且miDebuggerPath指向GDB。很多混用两个工具链的人在这里翻车记住这个区别。注意一个细节调试信息类型必须是Debug。默认的CMake构建是Debug模式与否取决于CMAKE_BUILD_TYPE。命令行构建时如果没指定CMake默认不生成调试信息。所以如果你想调试最好在CMakeLists.txt里加一行set(CMAKE_BUILD_TYPE Debug)或者在configure时用cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPEDebug设置完之后断点才会正常生效。VS Code对MSVC的调试支持已经很成熟设置好之后命中断点、查看变量、单步执行都没有任何问题。4.4 CMakePresets.json值得一开始就掌握的进阶配置VS Code的CMake Tools和命令行之间最推荐的交互方式是CMakePresets.json。它可以统一记录用哪个生成器、哪个构建类型、哪些宏定义让命令行和IDE共用一套配置。在项目根目录建一个CMakePresets.json{ version: 6, configurePresets: [ { name: windows-msvc-ninja, displayName: Windows MSVC (Ninja), generator: Ninja, binaryDir: ${sourceDir}/build, cacheVariables: { CMAKE_BUILD_TYPE: Debug } } ], buildPresets: [ { name: windows-msvc-ninja-build, configurePreset: windows-msvc-ninja } ] }有了这个文件后命令行构建直接cmake --preset windows-msvc-ninja cmake --build --preset windows-msvc-ninja-buildVS Code的CMake Tools插件会自动识别preset并且在Kit选择处让用户选windows-msvc-ninja。这样团队协作时每个人的配置都一致不再出现我机器上能跑你机器上不行的经典问题。这部分属于进阶内容等后面讲跨平台和团队协作时再展开细说。5. 常见错误清单与解决实录5.1 CMake Error: Unable to find a build program这个错误基本上是Ninja缺失或不在PATH里。报错信息往往类似CMake Error: CMake was unable to find a build program corresponding to Ninja. CMAKE_MAKE_PROGRAM is not set.解决路径很明确确认ninja --version能跑通然后重开终端让PATH刷新再到开发人员命令行里重新configure。如果Ninja确实装了但CMake还是不认可以手动指定cmake -S . -B build -G Ninja -DCMAKE_MAKE_PROGRAMC:/tools/ninja/ninja.exe5.2 CMake Error at .../CMakeDetermineCompilerID.cmake:9这个报错在列出的热搜词里出现了现实中也很典型。报错场景一般是CMake在Detecting CXX compiler ABI info或Check for working CXX compiler这一步挂了错误会指向cmakedeterminecompilerid.cmake第9行附近。这个问题本质是编译器探测失败。常见原因和对应解法在普通命令行里跑cmakecl.exe不在PATH中。这是最常见的。解决换成x64 Native Tools Command Prompt或者先执行vcvars64.bat。MSVC版本与CMake版本不匹配。比如老旧的MSVC 2015配全新CMake 4.x有时会有探测脚本兼容性问题。解决升级Build Tools到最新版或者换用版本相近的CMake。杀毒软件干扰。MSVC在探测时会生成临时文件并调用编译器某些杀毒软件会拦截这些临时进程。解决暂时关闭实时防护或者把构建目录加入白名单。系统临时目录不可写或权限受限。如果TEMP/TMP环境变量指向了不可写位置探测过程会失败。解决检查环境变量把临时目录改成可写的用户目录。我遇到CMC错误时通常的第一反应是清空build目录重来。因为CMake探测失败后会在缓存里留下半截状态不清缓存直接重跑往往会复现同样的错误清理后再跑成功率大幅提升。5.3 Qt项目装了MinGW版Qt还想用MSVC编译热搜词里出现频率很高的一条qt安装完mingw编译器后怎么安装msvc编译工具链。这个问题我在博客里被问过无数次统一回答一下。Qt官方预编译包分成MSVC版和MinGW版两者不兼容。你从Qt官网下载了qt-opensource-windows-x86-64-5.x.x-mingw_64.exe这种文件名那它里面带的库就是GCC编译的只认MinGW工具链。如果你想改用MSVC编译Qt项目不能只装MSVC编译器就完事还必须下载Qt官方提供的MSVC版预编译包文件名里通常有msvc2017_64或msvc2019_64字样。简单说Qt的库文件本身打包时绑定了ABI编译器不匹配就无法链接。另一个常见报错长这样CMake Error at C:/Qt/Qt5.9.4/5.9.4/msvc2017_64/lib/cmake/Qt5/Qt5Config.cmake:9这是CMAKE_PREFIX_PATH或Qt5_DIR指向了不存在的路径或者乱指向。Qt的CMake包路径被硬编码在CMakeLists里而路径写错、版本号对不上、或者编译器架构不匹配都会导致这个错误。解决思路确认安装的Qt版本与CMakeLists里的find_package(Qt5 REQUIRED COMPONENTS Widgets)版本一致。显式指定Qt路径例如configure时加参数-DCMAKE_PREFIX_PATHC:/Qt/5.9.4/msvc2017_64。删除build目录重configure。Qt的CMake缓存特别容易残留旧路径我经常改了一遍环境变量后忘了清缓存结果报错依旧。5.4 其他高频坑速查症状根因解决办法构建很慢单线程跑用了Makefile生成器或Ninja未并行换-G Ninja检查任务管理器CPU占用改代码后构建无变化缓存未更新或改错了文件确认保存比较build.ninja时间戳必要时清目录重来中文路径下编译失败cl.exe不支持部分非ASCII路径把项目放在纯英文路径下这是我能给的最实在的建议路径太长报错Windows MAX_PATH限制把项目根目录尽量放浅如D:\work\democl : fatal error C1083: Cannot open include fileinclude目录没配或拼错检查CMakeLists里的target_include_directories运行时提示找不到*.dll动态库不在exe旁边或PATH中把DLL拷到exe同目录或设置PATHCMake配置一直用旧编译器CMAKE_CXX_COMPILER缓存残留删build目录重配里面有几条是经验性的。比如中文路径不是说一定不行是没必要赌。C工具链在Windows上对中文路径的支持参差不齐麻烦远大于收益。我把所有项目统一放在D:\work\这种纯英文无空格路径下三年来没再遇到过路径类报错。5.5 一个我至今印象深刻的排查案例有一次一个同事在群里发截图说CMake configure报错内容指向cmakedeterminecompilerid.cmake:9他用的也是VS Code怎么都搞不定。我远程看他的环境发现他开了普通powershell在里面手动跑cmake --preset。cl.exe当然不在PATH里CMake自然探测不到编译器。我让他关闭所有终端重新打开VS Code然后在VS Code的终端里执行。VS Code的CMake Tools插件会帮用户加载MSVC环境所以内部终端里cl是可见的。configure一次就跑通了。这个案例的教训是MSVC的环境变量加载是整个工具链里最容易出错的环节新手往往忘了必须先进入开发者命令行环境这回事。很多教程默认读者知道但没人明说。6. 一些源于实践的使用习惯与接下来的探索方向最后分享几个我近几年沉淀下来的使用习惯不一定对所有项目都适用但在多数场景下能显著减少痛苦。习惯一build目录永远在项目目录下且可以随便删。我把build视为一个可再生的临时文件夹任何异常、任何不确定第一步永远是删掉build重新configure。CMake最烦人的问题里九成是缓存残留导致的。删了重来一般不超过30秒比排查一整天划算得多。习惯二区分开发命令行和普通命令行。我会在终端里创建一个固定标题的Tab专门用来跑MSVC环境需要编译时切换过去平时写代码、跑git都不受环境变量影响。这样既不会污染普通终端也不会在需要时找不到编译器。习惯三先让Ninja跑到全绿再管VS Code的插件按钮。我刚用CMake Tools时习惯性的先看状态栏按钮。后来发现插件那些按钮背后其实就是我在命令行敲的那几条命令。如果命令行能构建成功插件的Build按钮基本不会出问题反过来如果按钮点不动去命令行里跑一次就能看到真正的报错。所以我的调试路径永远是命令行优先排查插件负责方便。这套CMakeNinja/MSVC的组合目前是我在Windows上做C项目的主干工具链。它带来的最大改变不是编译速度变快这个表象而是整个开发体验重新变得可解释、可复现。遇到问题你能清楚知道是哪一层出的错是生成器的问题、调度的问题、还是编译器的问题而不是像以前那样对着VS的界面毫无头绪地乱点。下一篇我会围绕CMakeLists.txt的编写进阶展开包括多目录项目组织、静态库与动态库的构建、第三方依赖库的引入Eigen、OpenCV这些高频搜索项都会覆盖、以及如何用install()和CTest搭建起规范的工程骨架。如果你现在搭好了工具链、跑通了hello world那下一篇的内容正好能接上——你需要的下一块拼图已经在路上了。