1. 项目概述为什么要在Windows 11上折腾Ninja和JIT如果你是一个刚开始接触C项目构建或者刚从Visual Studio的“一键编译”舒适区走出来的开发者看到“Ninja”、“JIT”、“CMake”这些词可能会有点发怵。别担心这正是我几年前的状态。当时接手一个开源C项目发现它的构建说明里写着“推荐使用Ninja生成器”我是一头雾水。在Windows 11上尤其是家庭版配置一套高效、现代的C构建工具链确实是个有点门槛但绝对值得投入的“基建”工作。简单来说Ninja是一个专注于速度的小型构建系统它本身不负责复杂的项目描述而是忠实地执行由CMake这类高级构建系统生成的“构建计划”即build.ninja文件。它的哲学是“只做构建并且做到最快”。而JITJust-In-Time构建在这里并不是指Java或.NET里的运行时编译而是在C扩展开发中特别是像PyTorch C扩展、TensorFlow Ops这类场景指代一种动态编译模式你的C代码作为插件在宿主程序如Python解释器运行时才被编译和加载无需预先编译成静态库或DLL。这极大地提升了迭代开发效率你改一行C代码几乎能像改Python代码一样立刻测试。在Windows 11上做这件事有几个独特的挑战和优势。挑战在于Windows传统的构建生态以MSVC和Visual Studio项目文件为中心而Ninja和JIT构建更偏向于跨平台的“Unix风格”。优势则在于Windows 11对WSL 2和现代终端如Windows Terminal的支持已经非常成熟为我们打通了一条接近Linux体验的路径。但今天我们完全在原生Windows环境下操作不依赖WSL这能让你的工具链更纯粹与Windows上的IDE如VS Code集成也更顺畅。这篇文章我将带你从零开始在Windows 11上部署Ninja构建系统并完成一个简单的、可实操的C扩展JIT构建示例。目标是让你不仅“照做能成功”更能理解每一个步骤背后的“为什么”从而具备自己排查问题和优化流程的能力。无论你是想为Python加速还是构建高性能的本地模块这套流程都是一个坚实的起点。2. 环境准备与工具选型打造你的Windows C工坊在开始敲命令之前花点时间把“厨房”收拾好至关重要。在Windows上进行C开发工具链的清晰和纯净能避免未来无数的诡异错误。2.1 编译器MSVC还是MinGW这是第一个关键选择。Ninja只是一个任务执行器它需要调用底层的编译器如cl.exe和链接器link.exe。MSVCMicrosoft Visual C这是Windows平台的“原住民”编译器与系统兼容性最好特别是需要与Windows SDK交互或使用最新C标准特性时。它是我们本次教程的选择。你不需要安装完整的、几个G的Visual Studio IDE。微软提供了轻量级的“Build Tools for Visual Studio”只包含编译器、链接器、库和头文件。MinGW-w64 / GCC这是一个将GCC编译器移植到Windows的版本。它的优势是更接近Linux的编译体验生成的是原生Windows程序而非Cygwin那样的POSIX模拟层。如果你追求跨平台一致性或者项目本身基于GCC可以选择它。但需要注意库的兼容性问题。我们的选择与理由为了最广泛的兼容性和利用Windows最新的C特性如C20 Modules我们选择MSVC。我们将通过安装“Visual Studio Build Tools”来获取它。这确保了与Python扩展通常使用MSVC编译的无缝对接。操作步骤访问 Visual Studio 下载页面 找到“Visual Studio 2022 生成工具”并下载安装程序。运行安装程序。在“工作负载”选项卡中必须勾选“使用C的桌面开发”。在右侧的“安装详细信息”中确保包含了“MSVC v143 - VS 2022 C x64/x86 生成工具”和“Windows 10/11 SDK”。安装位置可以自定义但记住路径。安装完成后关键一步你需要从“开始”菜单找到“Developer Command Prompt for VS 2022”或“Developer PowerShell for VS 2022”并打开。这个终端环境已经配置好了cl.exe、link.exe等工具的环境变量。我们后续的所有操作建议都在这个终端或在其环境变量设置好的终端如VS Code集成终端中进行。注意很多新手会直接在普通的CMD或PowerShell里输入cl然后得到“不是内部或外部命令”的错误根本原因就是缺少这个特定的开发环境。你可以通过运行cl命令来测试是否配置成功。2.2 包管理器vcpkg还是Conan现代C项目离不开第三方库。手动下载、编译、配置库路径是痛苦的源泉。vcpkg微软推出的开源C库管理器与Visual Studio和CMake集成度极高。它从源码编译库确保与你当前工具链的ABI兼容性。库数量庞大管理方便。Conan一个去中心化的C/C包管理器功能强大支持多种构建系统更灵活。我们的选择与理由鉴于我们主要使用MSVC和CMake且vcpkg在Windows上的体验非常顺畅我们选择vcpkg。它将成为我们获取依赖库例如我们后面示例中可能用到的pybind11的主要方式。操作步骤打开刚才配置好的“Developer PowerShell for VS 2022”。选择一个你喜欢的目录避免中文和空格路径克隆vcpkg仓库git clone https://github.com/microsoft/vcpkg.git cd vcpkg运行引导脚本.\bootstrap-vcpkg.bat可选但推荐将vcpkg集成到全局环境。这会让CMake自动发现vcpkg安装的包.\vcpkg integrate install成功后你会看到提示“Applied user-wide integration for this vcpkg root.”2.3 核心工具CMake与Ninja的安装这是我们的“大脑”和“四肢”。CMake项目配置工具。它读取你的CMakeLists.txt根据当前系统环境编译器、架构等生成对应的构建文件如Makefile或build.ninja。Ninja构建执行工具。运行CMake生成的build.ninja文件以极高的并行度调用编译器。安装CMake前往 CMake官网 下载Windows x64 Installer。安装时务必勾选“Add CMake to the system PATH for all users”或“Add CMake to the system PATH for current user”这样可以在任何终端直接使用cmake命令。安装Ninja Ninja的安装极其简单因为它就是一个单文件的可执行程序。访问 Ninja的GitHub发布页 。下载最新版本的ninja-win.zip。解压你会得到一个ninja.exe文件。将这个ninja.exe所在的目录例如D:\Tools\ninja添加到系统的PATH环境变量中。或者更简单粗暴的方法直接把ninja.exe复制到C:\Windows\System32目录下需要管理员权限。我推荐前者管理更清晰。验证安装 在“Developer PowerShell for VS 2022”中分别运行cmake --version ninja --version如果都能正确输出版本信息那么恭喜你核心工具链就绪了。2.4 代码编辑器VS Code的配置虽然我们可以纯命令行操作但一个好用的编辑器能提升效率。VS Code配合扩展是绝配。安装VS Code。安装以下扩展C/C(Microsoft)提供代码智能感知、调试等功能。CMake Tools(Microsoft)这是重中之重它提供了CMake项目的图形化配置、构建、调试、目标管理等功能与Ninja集成完美。配置VS Code的终端打开设置Ctrl,搜索“Terminal Integrated Default Profile: Windows”将其设置为“Developer PowerShell for VS 2022”或你自定义的、包含了开发环境变量的PowerShell。这样在VS Code内部打开的集成终端就直接具备了编译环境。至此你的“工坊”已经搭建完毕。我们有了编译器MSVC、包管理器vcpkg、项目配置器CMake、构建器Ninja和编辑器VS Code。接下来让我们进入实战。3. 初识Ninja从CMake项目到闪电构建很多人以为用了Ninja就是用了不同的命令其实不然。Ninja的角色是执行者而CMake是指挥官。我们的工作流程通常是CMake配置 - CMake生成生成Ninja文件 - Ninja构建。3.1 创建一个最简单的CMake项目让我们先建立一个最简单的项目来理解这个流程。创建一个新目录例如hello_ninja并在其中创建两个文件CMakeLists.txt:cmake_minimum_required(VERSION 3.15) # 指定CMake最低版本 project(HelloNinja LANGUAGES CXX) # 定义项目名和语言CXX即C # 设置C标准 set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 添加一个可执行目标 add_executable(hello_ninja main.cpp)main.cpp:#include iostream int main() { std::cout Hello, Ninja Build System on Windows 11! std::endl; return 0; }3.2 使用CMake生成Ninja构建文件现在打开你的“Developer PowerShell for VS 2022”导航到hello_ninja目录。关键命令来了# 创建一个构建目录保持源码树干净是CMake的推荐做法 mkdir build cd build # 使用CMake配置并生成Ninja构建文件 # -G 参数指定生成器Generator这里就是“Ninja” # .. 表示CMakeLists.txt在上一级目录 cmake -G Ninja ..执行成功后你会在build目录下看到一堆文件其中最重要的就是build.ninja。这个文件是Ninja能理解的“构建脚本”里面详细定义了如何编译每个源文件、如何链接等所有规则。同时你也会看到CMakeCache.txt它缓存了你的配置比如编译器路径、选项等。3.3 使用Ninja进行构建生成build.ninja后构建就变得非常简单ninja或者如果你想明确指定目标ninja hello_ninja你会看到Ninja以极快的速度开始编译。它的输出非常简洁默认只显示正在执行的命令。如果你想看更详细的输出可以使用-vverbose选项ninja -v但这通常只在调试构建规则时有用。构建完成后在build目录下或者build/Debug取决于配置就会生成hello_ninja.exe。运行它.\hello_ninja.exe如果看到“Hello, Ninja Build System on Windows 11!”那么你的第一个Ninja项目就成功了3.4 Ninja的核心优势与常用命令增量构建极快Ninja会严格检查文件时间戳和依赖关系。如果你只修改了main.cpp再次运行ninja它只会重新编译main.cpp并重新链接过程几乎是瞬间完成的。相比之下某些构建系统可能会重新评估整个CMakeLists。并行构建Ninja默认会使用所有可用的CPU核心进行并行构建。你可以用-j N来指定并行任务数例如ninja -j 8。这在编译大型项目时优势巨大。清理构建ninja -t clean可以清理所有构建产物。但注意它不会删除build.ninja和CMakeCache.txt。如果你想彻底从头开始直接删除整个build目录更干脆。查看依赖ninja -t deps可以输出依赖信息对于调试复杂的依赖关系很有帮助。编译数据库ninja -t compdb可以生成compile_commands.json文件这个文件被很多代码分析工具如Clangd VS Code的C/C扩展的智能感知用来理解项目的编译指令极大提升代码跳转和补全的准确性。这是一个非常实用的技巧。实操心得在VS Code中如果你使用了CMake Tools扩展上述过程可以完全图形化完成。你只需要打开项目文件夹VS Code会自动检测到CMakeLists.txt底部状态栏会出现一系列CMake工具按钮。你可以在这里选择“Kit”即工具链如“Visual Studio Community 2022 Release - amd64”和“Build Target”。当你点击“Configure”时CMake Tools通常会默认使用Ninja作为生成器如果它找到了Ninja。之后点击“Build”按钮背后调用的就是ninja命令。这比纯命令行更方便尤其是管理多个构建配置Debug/Release时。4. 深入JIT构建为Python创建C扩展现在来到更激动人心的部分JIT构建C扩展。这里的“JIT”并非严格的运行时编译而是一种构建模式我们的C代码作为Python模块的源码在import时或通过特定命令触发编译并动态加载生成的二进制模块。我们将使用pybind11这个优秀的库来实现。它允许你用C编写代码并自动生成Python的绑定就像写Cython一样自然但性能是纯C级别的。4.1 使用vcpkg安装pybind11首先确保你在之前安装好的vcpkg目录下。在“Developer PowerShell”中# 安装pybind11。vcpkg默认编译并安装库到它的特定目录。 .\vcpkg install pybind11安装完成后vcpkg会提示你如何使用这个包。对于CMake项目最佳实践是使用CMake的Toolchain文件。4.2 创建Pybind11 JIT扩展项目新建一个目录pybind11_jit_demo结构如下pybind11_jit_demo/ ├── CMakeLists.txt ├── setup.py # 用于pip install -e . 或 python setup.py develop 的JIT构建入口 ├── mymodule/ │ ├── CMakeLists.txt │ ├── bindings.cpp │ └── __init__.py └── ...1. 顶层的CMakeLists.txt 这个文件负责配置项目找到pybind11并添加子目录。cmake_minimum_required(VERSION 3.15) project(MyPybind11Module LANGUAGES CXX) # 关键指定C标准pybind11需要C11或更高 set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 寻找pybind11包。 # 方法1如果你全局集成了vcpkgCMake会自动从vcpkg路径查找。 # 方法2推荐更明确通过CMAKE_TOOLCHAIN_FILE指定vcpkg。 # 我们假设你通过方法1或命令行参数-DCMAKE_TOOLCHAIN_FILE...来指定。 find_package(pybind11 CONFIG REQUIRED) # 或者使用pybind11提供的更简单的CMake函数需要include # include(FetchContent) # FetchContent_Declare(pybind11 ...) # 这里省略我们假设用vcpkg安装。 # 添加子目录里面是我们的模块源码 add_subdirectory(mymodule)2. 模块层的CMakeLists.txt (mymodule/CMakeLists.txt) 这个文件定义具体的模块目标。# 定义一个pybind11模块。 # MODULE表示生成一个动态库在Windows上是.dll但pybind11会将其重命名为.pyd。 # my_module是内部目标名mymodule是最终生成的Python模块名。 pybind11_add_module(my_module bindings.cpp) # 你可以在这里添加额外的包含目录、编译定义或链接库。 # target_include_directories(my_module PRIVATE ...) # target_link_libraries(my_module PRIVATE ...)3. C绑定代码 (mymodule/bindings.cpp)#include pybind11/pybind11.h int add(int i, int j) { return i j; } namespace py pybind11; // PYBIND11_MODULE是一个宏它创建了模块的入口点。 // 第一个参数mymodule必须与pybind11_add_module里的模块名完全一致也是Python中import的名字。 // 第二个参数m是一个py::module_对象代表这个模块。 PYBIND11_MODULE(mymodule, m) { m.doc() pybind11 example plugin; // 可选的模块文档字符串 // 将C函数add暴露给Python并命名为add m.def(add, add, A function which adds two numbers); // 你也可以暴露类、枚举等这里只是一个简单示例。 }4. Python的__init__.py (mymodule/init.py) 这个文件可以空着或者用来做模块的初始化或重导出。为了支持JIT构建我们通常会在顶层的setup.py中处理。4.3 实现JIT构建的关键setup.py这是实现“JIT”感觉的核心。我们使用setuptools的setup函数并配合CMakeBuild扩展来实现。我们需要一个自定义的build_ext类。顶层的setup.pyimport os import sys import subprocess import platform from pathlib import Path from setuptools import setup, Extension from setuptools.command.build_ext import build_ext class CMakeExtension(Extension): 一个自定义的Extension类用于触发CMake构建。 def __init__(self, name, sourcedir): Extension.__init__(self, name, sources[]) self.sourcedir os.path.abspath(sourcedir) class CMakeBuild(build_ext): 自定义的build_ext命令用CMake和Ninja来构建扩展。 def run(self): try: out subprocess.check_output([cmake, --version]) except OSError: raise RuntimeError( CMake must be installed to build the following extensions: , .join(e.name for e in self.extensions)) # 为每个扩展进行构建 for ext in self.extensions: self.build_extension(ext) def build_extension(self, ext): extdir os.path.abspath( os.path.dirname(self.get_ext_fullpath(ext.name))) # 创建构建目录 build_temp os.path.join(self.build_temp, ext.name) if not os.path.exists(build_temp): os.makedirs(build_temp) # CMake配置参数 cmake_args [ f-DCMAKE_LIBRARY_OUTPUT_DIRECTORY{extdir}, f-DCMAKE_ARCHIVE_OUTPUT_DIRECTORY{extdir}, -DCMAKE_BUILD_TYPE (Debug if self.debug else Release), -G, Ninja, # 指定使用Ninja生成器 ] # 如果提供了vcpkg工具链文件可以在这里添加 vcpkg_toolchain os.getenv(VCPKG_ROOT) if vcpkg_toolchain: vcpkg_toolchain_file os.path.join(vcpkg_toolchain, scripts, buildsystems, vcpkg.cmake) if os.path.exists(vcpkg_toolchain_file): cmake_args.append(f-DCMAKE_TOOLCHAIN_FILE{vcpkg_toolchain_file}) print(fUsing vcpkg toolchain: {vcpkg_toolchain_file}) # 调用CMake配置 subprocess.check_call([cmake, ext.sourcedir] cmake_args, cwdbuild_temp) # 调用Ninja构建 subprocess.check_call([ninja], cwdbuild_temp) setup( namemymodule, version0.1.0, authorYour Name, descriptionA test project using pybind11 and JIT build, long_description, ext_modules[CMakeExtension(mymodule, sourcedir.)], # 扩展名和源码目录 cmdclassdict(build_extCMakeBuild), zip_safeFalse, python_requires3.6, )4.4 进行JIT构建与测试现在在你的项目根目录pybind11_jit_demo下打开配置好MSVC环境的终端。以“可编辑”模式安装这是JIT构建的典型用法。它不会将编译好的包复制到site-packages而是在原位置创建一个链接。当你修改C代码后重新导入模块会触发重新构建。pip install -e .这个命令会执行setup.py中的build_ext命令也就是我们的CMakeBuild类。你会看到CMake和Ninja的输出最终编译生成mymodule.pydWindows上的Python扩展模块。测试模块 打开Python解释器或在同一终端运行Python脚本import mymodule print(mymodule.add(1, 2)) # 输出3成功修改后重新加载 现在去修改mymodule/bindings.cpp比如把加法改成乘法。int add(int i, int j) { return i * j; // 改为乘法 }保存后在Python中你需要重新导入模块。由于是动态库直接reload可能不行最简单的方法是重启Python解释器或者使用importlib.reload(mymodule)注意reload的使用限制。更符合“JIT”工作流的是再次运行pip install -e .增量构建很快或者直接运行python setup.py build_ext --inplace它会只执行构建步骤将新的.pyd文件生成到当前目录。核心原理剖析这里的“JIT”本质是“按需构建”Build on Demand。pip install -e .或setup.py build_ext触发了CMake配置和Ninja构建。Ninja的增量构建特性使得后续的重新构建速度极快感觉就像即时编译一样。这与真正的运行时JIT如LLVM JIT不同但达到了类似的开发体验编辑C代码 - 快速重新构建 - 在Python中测试循环非常迅速。5. 高级配置与性能调优掌握了基础流程后我们可以进一步优化让这套工具链更顺手、更强大。5.1 配置多种构建类型Debug/Release在软件开发中Debug版本包含调试信息优化关闭Release版本进行大量优化去除调试信息。CMake可以很方便地管理这些。在命令行中通过-DCMAKE_BUILD_TYPE指定# 在build目录下 cmake -G Ninja -DCMAKE_BUILD_TYPEDebug .. ninja # 或者 cmake -G Ninja -DCMAKE_BUILD_TYPERelease .. ninja在setup.py中我们通过self.debug来判断见前面代码。在VS Code的CMake Tools中你可以通过状态栏的“Build Type”轻松切换。注意事项pybind11模块在Debug模式下链接的是Python的调试库通常叫python3_d.lib你需要安装对应的Python调试版本。对于纯开发调试使用Release模式链接通常的Python库也是可以的只是无法在C扩展内部进行源码级调试。如果需要进行C扩展调试建议安装Python Debug版本并配置好。5.2 利用CCache加速编译CCache是一个编译器缓存可以缓存之前的编译结果当同样的编译任务再次出现时直接使用缓存大幅加速重复构建比如清理后重建、切换分支。安装CCache可以从 ccache官网 下载Windows版本解压并将ccache.exe路径加入PATH。告诉CMake使用CCache。最方便的方法是在调用CMake前设置环境变量$env:CMAKE_CXX_COMPILER_LAUNCHER ccache cmake -G Ninja ..或者在CMakeLists.txt中设置find_program(CCACHE_PROGRAM ccache) if(CCACHE_PROGRAM) set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ${CCACHE_PROGRAM}) set_property(GLOBAL PROPERTY RULE_LAUNCH_LINK ${CCACHE_PROGRAM}) endif()首次编译会稍慢因为要填充缓存。之后再进行构建特别是增量构建或完全清理后的构建速度会有显著提升。5.3 在VS Code中无缝集成调试这是提升开发效率的利器。配置好VS Code的launch.json你可以直接在VS Code里对Python脚本进行调试并且可以单步跳入C扩展的代码中。确保你使用VS Code的CMake Tools扩展配置并构建了项目生成build.ninja和可执行文件/库。在VS Code中打开项目根目录。切换到“运行和调试”视图CtrlShiftD点击“创建 launch.json 文件”选择“Python”。编辑生成的.vscode/launch.json一个支持混合调试的配置可能如下{ version: 0.2.0, configurations: [ { name: Python: Debug C Extension, type: python, request: launch, program: ${file}, console: integratedTerminal, justMyCode: false, // 必须设为false才能进入C代码 env: { // 确保Python能找到你编译的.pyd文件 PYTHONPATH: ${workspaceFolder}/build/lib:${env:PYTHONPATH} }, // 以下配置用于附加C调试器 windows: { type: cppvsdbg, request: attach, processId: ${command:pickProcess} } } ] }更优雅的方式是使用“复合启动配置”同时启动Python调试器和C调试器。这需要更复杂的配置但CMake Tools扩展通常能帮你自动生成一部分。核心思路是让C调试器附加到Python解释器进程上。实操心得对于简单的扩展调试一个更直接的方法是在C代码中需要调试的地方比如函数入口加入__debugbreak()MSVC内置或int 3内联汇编指令来触发断点。然后用Debug模式编译扩展在Python中运行脚本。当执行到断点时会触发一个异常此时你可以用Visual Studio不是VS Code的“调试-附加到进程”功能选择你的Python解释器进程进行附加和调试。虽然麻烦点但在紧急排查问题时很有效。6. 常见问题与排查技巧实录即使按照步骤操作你也可能会遇到一些坑。这里记录了我踩过的一些典型问题和解决方法。6.1 “找不到pybind11/pybind11.h”或类似错误症状CMake配置或编译时报错fatal error C1083: Cannot open include file: pybind11/pybind11.h。原因CMake没有正确找到pybind11的安装位置。排查确认vcpkg已安装pybind11.\vcpkg list | findstr pybind11。确认CMake使用了vcpkg的工具链文件。在CMake配置命令中显式指定cmake -G Ninja -DCMAKE_TOOLCHAIN_FILE[你的vcpkg目录]/scripts/buildsystems/vcpkg.cmake ..。在setup.py中我们通过环境变量VCPKG_ROOT来尝试自动查找。检查vcpkg安装的pybind11是否匹配当前架构x64/x86。通常vcpkg默认安装x64版本。如果你的CMake试图为x86配置就会找不到。确保架构一致。6.2 链接错误LNK2001, LNK2019等症状构建时在链接阶段失败报错“无法解析的外部符号”。原因最常见的原因是Python库的链接问题。Debug和Release版本、不同Python版本如3.8 vs 3.11的库不兼容。排查检查Python版本确保你pip install时使用的Python解释器与CMake找到的Python是同一个。在CMake配置后查看CMakeCache.txt中的Python_EXECUTABLE、Python_LIBRARY等变量的值是否正确指向了你预期的Python。检查构建类型确保整个工具链的构建类型一致。如果你用-DCMAKE_BUILD_TYPERelease配置的CMake那么setup.py中的self.debug应该是False。在VS Code中确保CMake Tools的活动配置与你运行的Python环境匹配。手动指定Python路径可以在CMake命令中强制指定cmake -G Ninja -DPython_ROOT_DIRC:\path\to\your\python ..。6.3 Ninja报错“build.ninja missing and no rules specified”症状直接运行ninja命令而不是在CMake生成的构建目录下运行。解决Ninja必须在包含build.ninja文件的目录下运行。请确保你的当前工作目录是执行过cmake -G Ninja ..的那个build目录。6.4 模块导入错误ImportError: DLL load failed症状Python中import mymodule失败提示DLL加载失败。原因生成的.pyd文件依赖的某些DLL如特定的MSVC运行时库MSVCP140.dllVCRUNTIME140_1.dll在Python环境的路径下找不到。排查使用Dependency Walker或dumpbin /dependents mymodule.pyd命令查看.pyd文件依赖哪些DLL。确保你的系统安装了对应版本的Visual C Redistributable。对于MSVC 2022v143需要安装最新的VC Redist。通常安装Visual Studio Build Tools时会包含但纯净的系统可能需要单独安装。尝试将编译好的.pyd文件复制到Python安装目录的DLLs文件夹或Lib\site-packages目录下再导入有时能解决路径问题。6.5 增量构建失效每次都全部重新编译症状只修改了一个cpp文件但运行ninja时仍然编译了很多文件。原因可能是.ninja_deps或.ninja_log文件损坏或者头文件依赖关系没有正确捕获。解决尝试先运行ninja -t clean然后再ninja。如果问题依旧删除整个build目录重新用CMake生成。检查你的CMakeLists.txt确保使用target_sources()等现代CMake命令来添加源文件这有助于CMake生成更准确的依赖关系。对于复杂的头文件包含CMake和Ninja可能无法自动捕获所有依赖。可以尝试在CMake中设置set(CMAKE_DEPENDS_IN_PROJECT_ONLY ON)但这并非万能。最根本的是确保CMakeLists.txt编写规范。6.6 在Windows 11家庭版上安装Docker相关问题的规避虽然本文主题不涉及Docker但热词中提到了。需要明确的是在Windows 11家庭版上直接安装Docker Desktop确实会遇到问题因为它需要Hyper-V而家庭版不包含此功能。通常的替代方案是使用WSL 2后端或者使用旧版的Docker Toolbox。但这与本文的原生Windows NinjaC扩展开发路径是两条不同的路线。本文选择的环境MSVC, vcpkg, CMake, Ninja完全可以在家庭版上流畅运行不依赖WSL或Docker。如果你需要进行Linux兼容性测试再考虑配置WSL 2。这套从Ninja部署到JIT构建C扩展的流程是我在Windows上进行高效C开发的核心工作流。它摆脱了庞大IDE的束缚获得了极快的构建速度并且通过pybind11将C的强大性能无缝带入Python生态。一开始配置可能会花点时间但一旦跑通你就会发现它的价值——清晰、快速、可重复并且完全由文本文件CMakeLists.txt, setup.py定义非常适合版本控制和团队协作。希望这篇详尽的指南能帮你顺利上车少走弯路。如果在实践中遇到新的问题不妨多看看CMake、Ninja和pybind11的官方文档社区的解决方案通常也很丰富。
