WiredTiger 数据库存储引擎 CMake 构建指南从依赖安装到 C/C 测试套件运行【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo本篇技术指南围绕 MongoDB 仓库内嵌的 WiredTiger 存储引擎位于 src/third_party/wiredtiger的官方 CMake 构建文档展开系统讲解其构建依赖、跨平台安装方式、配置与编译流程、核心构建选项、编译器切换以及基于 CTest 的 C/C 测试运行方法。读完本文你将掌握在 Linux、macOS、Windows 及 Docker 环境下完整构建 WiredTiger 静态库/动态库与 Python API 的实战方案并能结合 base.cmake 等构建脚本理解每个选项背后的依赖解析与宏定义机制。构建前的依赖准备WiredTiger 的 CMake 构建有明确的硬性依赖与推荐依赖二者缺一不可或影响构建效率。硬性依赖必须安装依赖版本要求用途说明C11 编译器gcc8.5 /clang7.01 / Windows 上使用Visual Studio 2022编译 WiredTiger 核心库cmake3.10官方安装说明见 https://cmake.org/install/配置与生成构建系统python3构建 Python API 或运行测试其中编译器要求支持 C11 标准这是 WiredTiger 核心代码的最低语言标准要求。推荐依赖改善构建体验依赖作用ninja替代make的并行构建工具显著提升增量构建速度ccache编译缓存重复构建时跳过未变更文件的编译Python API 的额外依赖若需要编译 Python API还必须安装python3-dev提供 Python 开发头文件用于构建 Python 绑定swig用于生成 Python 绑定的胶水代码。从 .devcontainer/Dockerfile 可以看到 WiredTiger 官方开发镜像实际安装的完整依赖清单cmake、ninja-build、ccache、clang、gcc/g、gdb、lld/lldb、python3-dev、swig、liblz4-dev、libsnappy-dev、libsodium-dev、libzstd-dev、zlib1g-dev等可作为本地环境依赖的对照基准。各平台依赖安装命令Ubuntu / Debian在 Ubuntu 18.04 上验证过sudo apt-get install cmake # 可选 ... sudo apt-get install cmake-curses-gui # ccmake 图形化配置界面 sudo apt-get install ccache sudo apt-get install ninja-build sudo apt-get install python3-dev swig # 构建 Python API 时需要cmake-curses-gui对应文档中提到的ccmake交互式配置工具安装后即可在终端内动态调整构建选项。macOSHomeBrewbrew install cmake # 可选 ... brew install ninja brew install ccache brew install python brew install swigWindowsChocolateychoco install cmake # 可选 ... choco install ninja choco install ccache --version3.7.9 choco install swig choco install python --pre注意 Windows 上除上述依赖外还需要 Visual Studio 2022 作为编译器文档明确要求CMake 会通过-G Visual Studio 17 2022或-G Ninja配合 MSVC 工具链完成配置。使用 Docker 快速搭建构建环境仓库自带一个预装了全部依赖的开发镜像定义位于 .devcontainer/Dockerfile无需手动安装任何依赖即可开始构建docker build -t wiredtiger-dev .devcontainer docker run -it -v $PWD:/workdir wiredtiger-devdocker run通过-v $PWD:/workdir将当前目录挂载进容器的/workdirDockerfile 中通过WORKDIR /workdir设定从而在容器内直接构建宿主机上的 WiredTiger 源码。镜像内以非 root 用户wiredtiger运行并预建了 Python 虚拟环境见 Dockerfile 中的python -m venv与ENV PATH设置。此外.devcontainer/devcontainer.json 将该镜像注册为Dev Container可在 VS Code 等支持 Dev Container 的编辑器中直接打开仓库并使用预装的clangd、CMake Tools、Python 等扩展进行开发调试其C_Cpp.intelliSenseEngine被显式禁用并指定clangd.path表明官方推荐以 clangd 作为 C/C 智能感知引擎。构建 WiredTiger 库三步走构建过程遵循标准的 CMake 流程新建构建目录 → 配置 → 编译。第一步配置构建# 新建独立构建目录保持源码目录干净 $ mkdir build cd build # 执行 cmake 配置可选 -G Ninja 生成 ninja 构建文件 $ cmake ../. ... -- Configuring done -- Generating done -- Build files have been written to: /home/wiredtiger/build文档建议在 WiredTiger 仓库顶层目录下执行上述命令。强烈建议使用独立构建目录out-of-source build这样源码树不会被生成物污染且可同时维护多个不同配置的构建目录。第二步执行编译$ make ... [211/211 (100%) 2.464s] Creating library symlink libwiredtiger.so输出末尾的libwiredtiger.so表明默认配置下产出的是共享库。如果配置阶段传入了-G Ninja此处应改用ninja命令执行编译。第三步可选安装如需将库安装到指定目录在配置时指定-DCMAKE_INSTALL_PREFIXpath-to-install-directory构建完成后执行make install或ninja install。安装规则定义在 cmake/install/install.cmake同时会生成wiredtiger.pc供 pkg-config 使用模板见 cmake/install/wiredtiger.pc.in。核心配置选项详解文档列出的配置选项全部定义于 cmake/configs/base.cmake并在配置阶段写入 wiredtiger_config.h模板。以下逐项说明其语义、默认值与源码层面的实际影响压缩器扩展ENABLE_LZ4/ENABLE_SNAPPY/ENABLE_ZLIB/ENABLE_ZSTD选项作用默认值-DENABLE_LZ41构建 lz4 压缩器扩展检测到 lz4 库时默认开启-DENABLE_SNAPPY1构建 snappy 压缩器扩展检测到 snappy 库时默认开启-DENABLE_ZLIB1构建 zlib 压缩器扩展检测到 zlib 库时默认开启-DENABLE_ZSTD1构建 libzstd 压缩器扩展检测到 zstd 库时默认开启从源码看默认值并非写死的base.cmake通过HAVE_LIBLZ4/HAVE_LIBSNAPPY/HAVE_LIBZ/HAVE_LIBZSTD这几个由库探测得出的变量决定是否默认开启且这些选项带有DEPENDS_ERROR ON语义——如果用户显式设置-DENABLE_LZ41而系统上找不到 lz4 库配置阶段会直接报Failed to find lz4 library致命错误而不是静默回退为关闭。库探测逻辑由 cmake/third_party/lz4.cmake 等文件调用wt_find_library定义于 cmake/helpers.cmake完成其查找链路依次为find_package→pkg-config→ 原始find_libraryfind_path。类似的压缩扩展还包括ENABLE_IAAIntel QPL 压缩器依赖HAVE_LIBQPL与ENABLE_MEMKINDNVRAM/SSD 块缓存所需分配器。静态/共享库ENABLE_STATIC-DENABLE_STATIC1将 WiredTiger 编译为静态库。base.cmake中默认ENABLE_STATICOFF、ENABLE_SHAREDON但WindowsWT_WIN上会强制反转强制静态编译以生成.lib文件并可通过.def文件见 cmake/configs/wiredtiger.def额外生成 DLL。另一个相关选项WITH_PIC控制是否生成位置无关代码但共享库目标无论该选项取值如何都会强制启用 PIC。诊断与调试选项选项作用默认值-DHAVE_DIAGNOSTIC1启用 WiredTiger 诊断模式非 Release 构建默认开启-DHAVE_REF_TRACK1追踪WT_REF结构的近期状态迁移诊断构建中强制开启-DHAVE_ERROR_LOG1启用错误日志诊断构建中强制开启-DHAVE_UNITTEST1启用基于 C Catch2 的单元测试关闭-DHAVE_ATTACH1失败时暂停等待调试器附加关闭-DENABLE_DEBUG_INFO1生成调试信息开启Release 关闭源码中有三个重要的联动逻辑诊断即调试信息base.cmake中if (HAVE_DIAGNOSTIC) set(ENABLE_DEBUG_INFO ON)诊断模式自动打开调试信息诊断即强开跟踪与日志if (HAVE_DIAGNOSTIC AND NOT HAVE_REF_TRACK)与if (HAVE_DIAGNOSTIC AND NOT HAVE_ERROR_LOG)两段逻辑确保诊断构建下HAVE_REF_TRACK与HAVE_ERROR_LOG必然为 ON与文档中“ref tracking always enabled in diagnostic build”的描述完全一致调试信息标志GNU/Clang 编译器下使用-g3 -gdwarf-4Clang 额外追加-glldb -fdebug-macroGCC 追加-ggdb3MSVC 下则为链接器追加/DEBUG生成 PDB。-g3级别允许在 gdb 中直接求值p S2C(session)这类宏见 base.cmake 中的注释。HAVE_REF_TRACK对应 wiredtiger_config.h.in 中的#cmakedefine HAVE_REF_TRACK 1最终会以宏形式进入 C 源码供WT_REF结构的状态机调试使用。Python APIENABLE_PYTHON-DENABLE_PYTHON1编译 Python API检测到 python 时默认开启。其默认值由base.cmake中的find_package(Python3 QUIET COMPONENTS Interpreter Development)决定——同时需要 Python 解释器与开发头文件才能自动开启。有两个特殊行为值得注意MSan/UBSan 构建下强制关闭 Python源码注释指出 Python 测试在 MSan/UBSan 下会因链接问题失败因此if(CMAKE_BUILD_TYPE_UPPER MATCHES ^(MSAN|UBSAN)$)时默认置 OFF可通过PYTHON3_REQUIRED_VERSION指定精确的 Python 版本格式major[.minor[.patch]]默认优先选择系统 PATH 中版本最高的 PythonSWIG_REQUIRED_VERSION默认要求 SWIG 主版本 4。安装路径CMAKE_INSTALL_PREFIX-DCMAKE_INSTALL_PREFIXpath-to-install-directory指定安装目录这是 CMake 的标准选项WiredTiger 的make install会把头文件、库文件及wiredtiger.pc安装到该前缀下。综合示例文档给出的一个典型组合$ cmake -DENABLE_STATIC1 -DHAVE_DIAGNOSTIC1 -DHAVE_ATTACH1 -G Ninja ../.即产出静态库 开启诊断模式附带调试信息与 ref track/error log 失败时暂停等待调试器 使用 Ninja 生成器。HAVE_ATTACH会在断言失败时让进程暂停方便开发者用 gdb/lldb 附加调试。更多选项ccmake与base.cmake配置阶段后可在构建目录中运行ccmake .打开交互式界面查看全部可用选项并动态修改$ cd build $ ccmake .文档明确说明全部配置选项可直接查看 cmake/configs/base.cmake。除文档列出的选项外该文件还定义了WT_ARCH/WT_OS目标架构x86/aarch64/ppc64le/s390x/riscv64/loongarch64与目标系统darwin/windows/linux通过 cmake/helpers.cmake 中的parse_filelist_source参与dist/filelist的解析决定编译哪些平台相关源文件ENABLE_STRICT默认 ON启用严格的编译器警告各编译器的严格告警标志定义于 cmake/strict 目录如gcc_strict.cmake、clang_strict.cmakeSPINLOCK_TYPE自旋锁实现选择pthread / gcc / msvc / pthread_adaptiveENABLE_ANTITHESIS启用 Antithesis 随机化测试库依赖 POSIX编译时注入-fsanitize-coveragetrace-pc-guardHAVE_CALL_LOG调用日志生成依赖诊断模式未开启诊断时配置报错CC_OPTIMIZE_LEVEL优化级别Debug 默认-OgRelease/RelWithDebInfo 默认-O2MSVC 下分别为/Od与/O2DYNAMIC_CRTWindows选择 MSVCRT 动态或静态运行时链接压缩/加密扩展的自动加载宏HAVE_BUILTIN_EXTENSION_LZ4/SNAPPY/ZLIB/ZSTD/IAA/SODIUM/KEY_PROVIDER会以#cmakedefine形式进入 wiredtiger_config.h.in实现压缩器/加密器的“自动加载”。构建类型Build Type与 Sanitizer 变体base.cmake引用的 cmake/configs/modes.cmake 定义了一套完整的构建模式体系默认构建类型为Debug源码注释明确说明主要用户是开发者希望获得尽可能多的诊断信息面向客户的发布应切换为 Release同时通过define_build_mode动态注册了ASan、UBSan、MSan、TSan、Coverage五个 sanitizer/覆盖率变体每个变体在define_build_mode内先用check_c_compiler_flag/check_cxx_compiler_flag校验编译器标志可用性再写入CMAKE_C_FLAGS_MODE等缓存变量cmake -DCMAKE_BUILD_TYPEASan ../. cmake -DCMAKE_BUILD_TYPERelease ../.其中 MSan 仅在 Clang 下可用UBSan/TSan/Coverage 在 MSVC 下被禁用DEPENDS NOT MSVC与base.cmake中“MSan/UBSan 关闭 Python”的联动相呼应。仓库还提供了 CMakePresets.json预置了linux-gcc、linux-clang、linux-v4-gcc等 presets分别通过MONGODBTOOLCHAIN_BIN环境变量指向/opt/mongodbtoolchain/v5/bin或 v4下的工具链方便在 MongoDB 官方 toolchain 环境中一键cmake --preset linux-clang。切换 GCC 与 ClangPOSIX 平台CMake 默认使用系统编译器cc。可通过在调用 CMake 前设置CC与CXX环境变量来选择具体编译器使用 GCC$ cd build $ CCgcc CXXg cmake ../.使用 Clang$ cd build $ CCclang CXXclang cmake ../.两个环境变量必须同时设置CC对应 C 编译器、CXX对应 C 编译器否则可能出现 C 与 C 编译器不一致的配置问题。切换编译器后建议删除或清空构建缓存目录再重新配置避免 CMake 缓存残留旧编译器信息。在 MongoDB 官方环境中也可直接使用 CMakePresets.json 的linux-gcc/linux-clangpresets 完成同样目标。运行 WiredTiger C/C 测试套件WiredTiger 的 CMake 构建会生成一套独立的 C/C 测试与 Python 测试套件分开由 CTest 驱动执行。运行全部测试在构建目录内执行ctest -j$(nproc)-j$(nproc)让测试按 CPU 核数并行执行nproc在 Linux 上返回逻辑核心数macOS 可替换为sysctl -n hw.ncpu。运行全部测试并输出详细日志ctest -j$(nproc) -VV-VV即--extra-verbose会打印每个测试的完整输出适合排查失败用例。运行指定测试# 注意-R 接受正则表达式匹配到的所有测试都会被运行 ctest -R test_name -j$(nproc)例如ctest -R pack -j$(nproc)会运行名称匹配pack正则的所有测试。-R支持正则语法可组合出更精确的过滤条件。更多选项可查阅ctest --help常用参数还包括--output-on-failure仅失败时打印输出、-L按标签过滤、-N仅列出测试不执行等。这套 C/C 测试与配置选项-DHAVE_UNITTEST1C Catch2 单元测试相互独立又彼此补充Catch2 单元测试由HAVE_UNITTEST控制编译而 ctest 聚合的是 WiredTiger 自带的一系列 C/C 测试可执行文件诊断模式HAVE_DIAGNOSTIC下测试断言能力更强配合HAVE_ATTACH可在断言失败时暂停进程供调试器附加是开发者定位缺陷的常用组合。小结WiredTiger 的 CMake 构建体系呈现三条清晰的线索依赖探测通过 cmake/helpers.cmake 的wt_find_library实现三级查找find_package→ pkg-config → 原始查找结果以HAVE_LIB*变量进入缓存默认策略cmake/configs/base.cmake 根据构建类型Debug/Release与库探测结果决定各选项默认值并通过DEPENDS_ERROR在显式开启但依赖缺失时直接报错用户覆盖命令行-D参数、ccmake交互界面、CMakePresets.json 三种方式均可动态调整最终通过 wiredtiger_config.h.in 的#cmakedefine机制落地为 C 宏贯穿整个 C/C 源码。掌握这套流程后你可以在本地、Docker 容器或 MongoDB 官方 toolchain 环境中自由组合压缩器扩展、诊断模式、sanitizer 构建类型与静态/共享库形态并用ctest快速验证构建正确性——这正是深入 WiredTiger 存储引擎源码开发与调试的起点。【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 WiredTiger 数据库存储引擎 CMake 构建指南：从依赖安装到 C/C++ 测试套件运行
WiredTiger 数据库存储引擎 CMake 构建指南从依赖安装到 C/C 测试套件运行【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo本篇技术指南围绕 MongoDB 仓库内嵌的 WiredTiger 存储引擎位于 src/third_party/wiredtiger的官方 CMake 构建文档展开系统讲解其构建依赖、跨平台安装方式、配置与编译流程、核心构建选项、编译器切换以及基于 CTest 的 C/C 测试运行方法。读完本文你将掌握在 Linux、macOS、Windows 及 Docker 环境下完整构建 WiredTiger 静态库/动态库与 Python API 的实战方案并能结合 base.cmake 等构建脚本理解每个选项背后的依赖解析与宏定义机制。构建前的依赖准备WiredTiger 的 CMake 构建有明确的硬性依赖与推荐依赖二者缺一不可或影响构建效率。硬性依赖必须安装依赖版本要求用途说明C11 编译器gcc8.5 /clang7.01 / Windows 上使用Visual Studio 2022编译 WiredTiger 核心库cmake3.10官方安装说明见 https://cmake.org/install/配置与生成构建系统python3构建 Python API 或运行测试其中编译器要求支持 C11 标准这是 WiredTiger 核心代码的最低语言标准要求。推荐依赖改善构建体验依赖作用ninja替代make的并行构建工具显著提升增量构建速度ccache编译缓存重复构建时跳过未变更文件的编译Python API 的额外依赖若需要编译 Python API还必须安装python3-dev提供 Python 开发头文件用于构建 Python 绑定swig用于生成 Python 绑定的胶水代码。从 .devcontainer/Dockerfile 可以看到 WiredTiger 官方开发镜像实际安装的完整依赖清单cmake、ninja-build、ccache、clang、gcc/g、gdb、lld/lldb、python3-dev、swig、liblz4-dev、libsnappy-dev、libsodium-dev、libzstd-dev、zlib1g-dev等可作为本地环境依赖的对照基准。各平台依赖安装命令Ubuntu / Debian在 Ubuntu 18.04 上验证过sudo apt-get install cmake # 可选 ... sudo apt-get install cmake-curses-gui # ccmake 图形化配置界面 sudo apt-get install ccache sudo apt-get install ninja-build sudo apt-get install python3-dev swig # 构建 Python API 时需要cmake-curses-gui对应文档中提到的ccmake交互式配置工具安装后即可在终端内动态调整构建选项。macOSHomeBrewbrew install cmake # 可选 ... brew install ninja brew install ccache brew install python brew install swigWindowsChocolateychoco install cmake # 可选 ... choco install ninja choco install ccache --version3.7.9 choco install swig choco install python --pre注意 Windows 上除上述依赖外还需要 Visual Studio 2022 作为编译器文档明确要求CMake 会通过-G Visual Studio 17 2022或-G Ninja配合 MSVC 工具链完成配置。使用 Docker 快速搭建构建环境仓库自带一个预装了全部依赖的开发镜像定义位于 .devcontainer/Dockerfile无需手动安装任何依赖即可开始构建docker build -t wiredtiger-dev .devcontainer docker run -it -v $PWD:/workdir wiredtiger-devdocker run通过-v $PWD:/workdir将当前目录挂载进容器的/workdirDockerfile 中通过WORKDIR /workdir设定从而在容器内直接构建宿主机上的 WiredTiger 源码。镜像内以非 root 用户wiredtiger运行并预建了 Python 虚拟环境见 Dockerfile 中的python -m venv与ENV PATH设置。此外.devcontainer/devcontainer.json 将该镜像注册为Dev Container可在 VS Code 等支持 Dev Container 的编辑器中直接打开仓库并使用预装的clangd、CMake Tools、Python 等扩展进行开发调试其C_Cpp.intelliSenseEngine被显式禁用并指定clangd.path表明官方推荐以 clangd 作为 C/C 智能感知引擎。构建 WiredTiger 库三步走构建过程遵循标准的 CMake 流程新建构建目录 → 配置 → 编译。第一步配置构建# 新建独立构建目录保持源码目录干净 $ mkdir build cd build # 执行 cmake 配置可选 -G Ninja 生成 ninja 构建文件 $ cmake ../. ... -- Configuring done -- Generating done -- Build files have been written to: /home/wiredtiger/build文档建议在 WiredTiger 仓库顶层目录下执行上述命令。强烈建议使用独立构建目录out-of-source build这样源码树不会被生成物污染且可同时维护多个不同配置的构建目录。第二步执行编译$ make ... [211/211 (100%) 2.464s] Creating library symlink libwiredtiger.so输出末尾的libwiredtiger.so表明默认配置下产出的是共享库。如果配置阶段传入了-G Ninja此处应改用ninja命令执行编译。第三步可选安装如需将库安装到指定目录在配置时指定-DCMAKE_INSTALL_PREFIXpath-to-install-directory构建完成后执行make install或ninja install。安装规则定义在 cmake/install/install.cmake同时会生成wiredtiger.pc供 pkg-config 使用模板见 cmake/install/wiredtiger.pc.in。核心配置选项详解文档列出的配置选项全部定义于 cmake/configs/base.cmake并在配置阶段写入 wiredtiger_config.h模板。以下逐项说明其语义、默认值与源码层面的实际影响压缩器扩展ENABLE_LZ4/ENABLE_SNAPPY/ENABLE_ZLIB/ENABLE_ZSTD选项作用默认值-DENABLE_LZ41构建 lz4 压缩器扩展检测到 lz4 库时默认开启-DENABLE_SNAPPY1构建 snappy 压缩器扩展检测到 snappy 库时默认开启-DENABLE_ZLIB1构建 zlib 压缩器扩展检测到 zlib 库时默认开启-DENABLE_ZSTD1构建 libzstd 压缩器扩展检测到 zstd 库时默认开启从源码看默认值并非写死的base.cmake通过HAVE_LIBLZ4/HAVE_LIBSNAPPY/HAVE_LIBZ/HAVE_LIBZSTD这几个由库探测得出的变量决定是否默认开启且这些选项带有DEPENDS_ERROR ON语义——如果用户显式设置-DENABLE_LZ41而系统上找不到 lz4 库配置阶段会直接报Failed to find lz4 library致命错误而不是静默回退为关闭。库探测逻辑由 cmake/third_party/lz4.cmake 等文件调用wt_find_library定义于 cmake/helpers.cmake完成其查找链路依次为find_package→pkg-config→ 原始find_libraryfind_path。类似的压缩扩展还包括ENABLE_IAAIntel QPL 压缩器依赖HAVE_LIBQPL与ENABLE_MEMKINDNVRAM/SSD 块缓存所需分配器。静态/共享库ENABLE_STATIC-DENABLE_STATIC1将 WiredTiger 编译为静态库。base.cmake中默认ENABLE_STATICOFF、ENABLE_SHAREDON但WindowsWT_WIN上会强制反转强制静态编译以生成.lib文件并可通过.def文件见 cmake/configs/wiredtiger.def额外生成 DLL。另一个相关选项WITH_PIC控制是否生成位置无关代码但共享库目标无论该选项取值如何都会强制启用 PIC。诊断与调试选项选项作用默认值-DHAVE_DIAGNOSTIC1启用 WiredTiger 诊断模式非 Release 构建默认开启-DHAVE_REF_TRACK1追踪WT_REF结构的近期状态迁移诊断构建中强制开启-DHAVE_ERROR_LOG1启用错误日志诊断构建中强制开启-DHAVE_UNITTEST1启用基于 C Catch2 的单元测试关闭-DHAVE_ATTACH1失败时暂停等待调试器附加关闭-DENABLE_DEBUG_INFO1生成调试信息开启Release 关闭源码中有三个重要的联动逻辑诊断即调试信息base.cmake中if (HAVE_DIAGNOSTIC) set(ENABLE_DEBUG_INFO ON)诊断模式自动打开调试信息诊断即强开跟踪与日志if (HAVE_DIAGNOSTIC AND NOT HAVE_REF_TRACK)与if (HAVE_DIAGNOSTIC AND NOT HAVE_ERROR_LOG)两段逻辑确保诊断构建下HAVE_REF_TRACK与HAVE_ERROR_LOG必然为 ON与文档中“ref tracking always enabled in diagnostic build”的描述完全一致调试信息标志GNU/Clang 编译器下使用-g3 -gdwarf-4Clang 额外追加-glldb -fdebug-macroGCC 追加-ggdb3MSVC 下则为链接器追加/DEBUG生成 PDB。-g3级别允许在 gdb 中直接求值p S2C(session)这类宏见 base.cmake 中的注释。HAVE_REF_TRACK对应 wiredtiger_config.h.in 中的#cmakedefine HAVE_REF_TRACK 1最终会以宏形式进入 C 源码供WT_REF结构的状态机调试使用。Python APIENABLE_PYTHON-DENABLE_PYTHON1编译 Python API检测到 python 时默认开启。其默认值由base.cmake中的find_package(Python3 QUIET COMPONENTS Interpreter Development)决定——同时需要 Python 解释器与开发头文件才能自动开启。有两个特殊行为值得注意MSan/UBSan 构建下强制关闭 Python源码注释指出 Python 测试在 MSan/UBSan 下会因链接问题失败因此if(CMAKE_BUILD_TYPE_UPPER MATCHES ^(MSAN|UBSAN)$)时默认置 OFF可通过PYTHON3_REQUIRED_VERSION指定精确的 Python 版本格式major[.minor[.patch]]默认优先选择系统 PATH 中版本最高的 PythonSWIG_REQUIRED_VERSION默认要求 SWIG 主版本 4。安装路径CMAKE_INSTALL_PREFIX-DCMAKE_INSTALL_PREFIXpath-to-install-directory指定安装目录这是 CMake 的标准选项WiredTiger 的make install会把头文件、库文件及wiredtiger.pc安装到该前缀下。综合示例文档给出的一个典型组合$ cmake -DENABLE_STATIC1 -DHAVE_DIAGNOSTIC1 -DHAVE_ATTACH1 -G Ninja ../.即产出静态库 开启诊断模式附带调试信息与 ref track/error log 失败时暂停等待调试器 使用 Ninja 生成器。HAVE_ATTACH会在断言失败时让进程暂停方便开发者用 gdb/lldb 附加调试。更多选项ccmake与base.cmake配置阶段后可在构建目录中运行ccmake .打开交互式界面查看全部可用选项并动态修改$ cd build $ ccmake .文档明确说明全部配置选项可直接查看 cmake/configs/base.cmake。除文档列出的选项外该文件还定义了WT_ARCH/WT_OS目标架构x86/aarch64/ppc64le/s390x/riscv64/loongarch64与目标系统darwin/windows/linux通过 cmake/helpers.cmake 中的parse_filelist_source参与dist/filelist的解析决定编译哪些平台相关源文件ENABLE_STRICT默认 ON启用严格的编译器警告各编译器的严格告警标志定义于 cmake/strict 目录如gcc_strict.cmake、clang_strict.cmakeSPINLOCK_TYPE自旋锁实现选择pthread / gcc / msvc / pthread_adaptiveENABLE_ANTITHESIS启用 Antithesis 随机化测试库依赖 POSIX编译时注入-fsanitize-coveragetrace-pc-guardHAVE_CALL_LOG调用日志生成依赖诊断模式未开启诊断时配置报错CC_OPTIMIZE_LEVEL优化级别Debug 默认-OgRelease/RelWithDebInfo 默认-O2MSVC 下分别为/Od与/O2DYNAMIC_CRTWindows选择 MSVCRT 动态或静态运行时链接压缩/加密扩展的自动加载宏HAVE_BUILTIN_EXTENSION_LZ4/SNAPPY/ZLIB/ZSTD/IAA/SODIUM/KEY_PROVIDER会以#cmakedefine形式进入 wiredtiger_config.h.in实现压缩器/加密器的“自动加载”。构建类型Build Type与 Sanitizer 变体base.cmake引用的 cmake/configs/modes.cmake 定义了一套完整的构建模式体系默认构建类型为Debug源码注释明确说明主要用户是开发者希望获得尽可能多的诊断信息面向客户的发布应切换为 Release同时通过define_build_mode动态注册了ASan、UBSan、MSan、TSan、Coverage五个 sanitizer/覆盖率变体每个变体在define_build_mode内先用check_c_compiler_flag/check_cxx_compiler_flag校验编译器标志可用性再写入CMAKE_C_FLAGS_MODE等缓存变量cmake -DCMAKE_BUILD_TYPEASan ../. cmake -DCMAKE_BUILD_TYPERelease ../.其中 MSan 仅在 Clang 下可用UBSan/TSan/Coverage 在 MSVC 下被禁用DEPENDS NOT MSVC与base.cmake中“MSan/UBSan 关闭 Python”的联动相呼应。仓库还提供了 CMakePresets.json预置了linux-gcc、linux-clang、linux-v4-gcc等 presets分别通过MONGODBTOOLCHAIN_BIN环境变量指向/opt/mongodbtoolchain/v5/bin或 v4下的工具链方便在 MongoDB 官方 toolchain 环境中一键cmake --preset linux-clang。切换 GCC 与 ClangPOSIX 平台CMake 默认使用系统编译器cc。可通过在调用 CMake 前设置CC与CXX环境变量来选择具体编译器使用 GCC$ cd build $ CCgcc CXXg cmake ../.使用 Clang$ cd build $ CCclang CXXclang cmake ../.两个环境变量必须同时设置CC对应 C 编译器、CXX对应 C 编译器否则可能出现 C 与 C 编译器不一致的配置问题。切换编译器后建议删除或清空构建缓存目录再重新配置避免 CMake 缓存残留旧编译器信息。在 MongoDB 官方环境中也可直接使用 CMakePresets.json 的linux-gcc/linux-clangpresets 完成同样目标。运行 WiredTiger C/C 测试套件WiredTiger 的 CMake 构建会生成一套独立的 C/C 测试与 Python 测试套件分开由 CTest 驱动执行。运行全部测试在构建目录内执行ctest -j$(nproc)-j$(nproc)让测试按 CPU 核数并行执行nproc在 Linux 上返回逻辑核心数macOS 可替换为sysctl -n hw.ncpu。运行全部测试并输出详细日志ctest -j$(nproc) -VV-VV即--extra-verbose会打印每个测试的完整输出适合排查失败用例。运行指定测试# 注意-R 接受正则表达式匹配到的所有测试都会被运行 ctest -R test_name -j$(nproc)例如ctest -R pack -j$(nproc)会运行名称匹配pack正则的所有测试。-R支持正则语法可组合出更精确的过滤条件。更多选项可查阅ctest --help常用参数还包括--output-on-failure仅失败时打印输出、-L按标签过滤、-N仅列出测试不执行等。这套 C/C 测试与配置选项-DHAVE_UNITTEST1C Catch2 单元测试相互独立又彼此补充Catch2 单元测试由HAVE_UNITTEST控制编译而 ctest 聚合的是 WiredTiger 自带的一系列 C/C 测试可执行文件诊断模式HAVE_DIAGNOSTIC下测试断言能力更强配合HAVE_ATTACH可在断言失败时暂停进程供调试器附加是开发者定位缺陷的常用组合。小结WiredTiger 的 CMake 构建体系呈现三条清晰的线索依赖探测通过 cmake/helpers.cmake 的wt_find_library实现三级查找find_package→ pkg-config → 原始查找结果以HAVE_LIB*变量进入缓存默认策略cmake/configs/base.cmake 根据构建类型Debug/Release与库探测结果决定各选项默认值并通过DEPENDS_ERROR在显式开启但依赖缺失时直接报错用户覆盖命令行-D参数、ccmake交互界面、CMakePresets.json 三种方式均可动态调整最终通过 wiredtiger_config.h.in 的#cmakedefine机制落地为 C 宏贯穿整个 C/C 源码。掌握这套流程后你可以在本地、Docker 容器或 MongoDB 官方 toolchain 环境中自由组合压缩器扩展、诊断模式、sanitizer 构建类型与静态/共享库形态并用ctest快速验证构建正确性——这正是深入 WiredTiger 存储引擎源码开发与调试的起点。【免费下载链接】mongoThe MongoDB Database项目地址: https://gitcode.com/GitHub_Trending/mo/mongo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考