ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

QuantLib 构建与测试完整指南:CMake、Autotools、MSVC 与 CI 工作流实战

QuantLib 构建与测试完整指南:CMake、Autotools、MSVC 与 CI 工作流实战 金融科技科学计算【免费下载链接】QuantLibThe QuantLib C library项目地址https://gitcode.com/gh_mirrors/qu/QuantLib点击查看免费下载本篇指南基于 QuantLib 仓库中的.agents/build-and-test.md文档系统梳理这个 C 金融计算库从零开始构建、运行测试套件以及理解 CI 持续集成矩阵的完整路径。读完你将掌握如何用 CMake Preset 一条命令完成编译如何用 Autotools 或 Visual Studio 构建等价产物如何精准定位并运行单个测试用例以及哪些 CI 矩阵覆盖非默认配置、何时需要手动触发它们。构建系统总览三条同等受支持的路径QuantLib 在 CI 中同时演练三套构建体系CMake、Autotools 和 Visual Studio 解决方案。从 AGENTS.md 的快速开始部分可以看出对于在全新检出fresh checkout中工作的 Agent 来说CMake 是路径最短的选择——因为 CMakePresets.json 已经完整拼写了工具链与选项无需记忆任何命令行细节而 Autotools 与 Visual Studio 解决方案同样受 CI 覆盖并持续验证。一个重要的约束来自 AGENTS.md任何新增、重命名或删除.hpp/.cpp源文件的改动都必须同时在三个构建系统中登记否则filelists.yml会在 PR 上直接失败。这意味着能编译不等于能过 CI三条构建路径是并列的验证标准。1. CMake面向 Agent 的推荐路径1.1 最简手工构建mkdir build cd build cmake .. -GNinja -DCMAKE_BUILD_TYPERelease \ -DQL_BUILD_TEST_SUITEON -DQL_BUILD_EXAMPLESON cmake --build .这段命令做了四件事创建独立构建目录避免污染源码树、选择 Ninja 生成器、以 Release 模式配置、显式开启测试套件与示例程序编译。在 CMakeLists.txt 中可以看到QL_BUILD_EXAMPLES与QL_BUILD_TEST_SUITE分别控制Examples/和test-suite/子目录是否被add_subdirectory引入——默认都为ON所以理论上可以省略这两个参数但显式写出能让构建意图一目了然。1.2 使用 CMake Preset仓库内置的 CMakePresets.json 通过继承链组合了编译器GCC/Clang/MSVC、生成器Ninja/Makefiles、构建类型Debug/Release/RelWithDebInfo与平台条件。文档中的示例即来自真实存在的 presetcmake --preset linux-gcc-ninja-release cmake --build build/linux-gcc-ninja-release这里linux-gcc-ninja-release实际继承自linux-gcc-baseg、ninja与_release三个隐藏 preset构建产物统一落在build/presetName目录下。除它之外仓库还提供linux-clang-ninja-release、windows-msvc-release、windows-clang-debug、apple-arm64-ninja-debug等覆盖 Linux/Windows/macOS 三平台、GCC/Clang/MSVC 三编译器的全套组合Windows 上还有windows-msvc-base指定的cl.exe与clang-cl.exe两套工具链。1.3 关键 CMake 选项及其默认值文档给出的选项与 CMakeLists.txt 中的option()声明逐一对得上以下是带源码注释的完整对照表CMake 选项默认值底层行为依据 CMakeLists.txtQL_BUILD_TEST_SUITEON控制add_subdirectory(test-suite)见 CMakeLists.txtQL_BUILD_EXAMPLESON控制add_subdirectory(Examples)见 CMakeLists.txtQL_ENABLE_PARALLEL_UNIT_TEST_RUNNEROFF开启后额外链接Threads库*nix 下还需rt库shm_open等见 CMakeLists.txtQL_COMPILE_WARNING_AS_ERROROFFCMake ≥ 3.24 时置CMAKE_COMPILE_WARNING_AS_ERRORON否则手动加-WerrorGNU/Clang或-WXMSVC见 CMakeLists.txtQL_USE_STD_CLASSESOFF一键开启全部QL_USE_STD_*系列目前实际动作是置QL_USE_STD_SHARED_PTRON见 CMakeLists.txt文档特别提醒CI 经常覆盖这些默认值。例如linux-ci-build-with-nonstandard-options与windows-ci-build-with-nonstandard-options两个 preset 就同时开启了QL_ENABLE_SESSIONS、QL_ENABLE_THREAD_SAFE_OBSERVER_PATTERN、QL_HIGH_RESOLUTION_DATE、QL_THROW_IN_CYCLES、QL_NULL_AS_FUNCTIONS、QL_USE_INDEXED_COUPON、QL_USE_STD_SHARED_PTR并把QL_COMPILE_WARNING_AS_ERROR置为ON见 CMakePresets.json。所以在本地以默认选项编译通过不代表 CI 的非默认矩阵也能通过。1.4 底层硬性要求源码佐证从 CMakeLists.txt 可确认三条不可绕过的约束C17 是下限CMAKE_CXX_STANDARD未指定时默认 17显式指定低于 17 直接FATAL_ERROR且默认关闭编译器扩展-stdc17而非-stdgnu17。Boost 是硬依赖find_package(Boost ${QL_BOOST_VERSION} REQUIRED)C20 及以上模式要求 Boost ≥ 1.75.0否则要求 ≥ 1.58.0同时定义BOOST_ALL_NO_LIB禁用 Boost 自动链接。默认开启警告防护QL_ENABLE_DEFAULT_WARNING_LEVEL默认ON对 MSVC 加-W3对 GNU/Clang/AppleClang 加-Wall -Wno-unknown-pragmas -Wno-array-bounds这正是为了让新代码在 GitHub workflows 下零警告通过。2. Autotools经典 configure/make 路线2.1 构建命令./autogen.sh ./configure --with-boost-include/path/to/boost make -j 4autogen.sh负责从 configure.ac 生成configure脚本--with-boost-include对应 configure.ac 中的AC_ARG_WITH将 Boost 头文件目录以-isystem方式注入CPPFLAGS。若 Boost 安装在系统标准路径此参数可省略。2.2 常用 configure 标志及其语义文档列出的标志全部真实存在于 configure.ac逐一对照源码中的AC_ARG_ENABLE说明如下configure 标志对应宏语义依据 configure.ac--enable-unity-buildUNITY_BUILD条件各目录源文件合并为单个编译单元加快库编译默认关闭configure.ac--enable-intradayQL_HIGH_RESOLUTION_DATE日期支持到微秒的日内精度Actual360/Actual365Fixed/ActualActual 等单调 day counter 会利用该精度实验性特性默认关闭configure.ac--enable-std-classesQL_USE_STD_SHARED_PTR--enable-std-pointers的快捷开关用std::shared_ptr替代 Boost 版本configure.ac--enable-thread-safe-observer-patternQL_ENABLE_THREAD_SAFE_OBSERVER_PATTERN使用线程安全但性能较低的 observer 模式SWIG 层运行在 JVM/.NET 等异步 GC 环境时建议开启configure.ac--enable-sessionsQL_ENABLE_SESSIONS单例按线程返回不同实例估值日期、index fixings 等设置变为线程私有configure.ac--enable-openmpOpenMP 检测configure 自动探测并注入OPENMP_CXXFLAGSconfigure.ac--enable-parallel-unit-test-runnerQL_ENABLE_PARALLEL_UNIT_TEST_RUNNER用并行 runner 执行测试套件以缩短多核机器上的运行时间要求 Boost ≥ 1.59 且支持 interprocess 测试configure.ac注意两个标志的联动--enable-sessions或--enable-thread-safe-observer-pattern任一开启就会触发 configure.ac 中的 Boost ≥ 1.58 与 Boost.Signals2 检查。2.3 Autotools 侧的测试与示例控制与 CMake 的QL_*变量对应configure.ac 还提供--enable-test-suite默认开启需能找到 Boost.Test禁用它的官方注释是Do not try this at home、--enable-examples默认只编译不安装、--enable-skip-examples、--enable-benchmark默认只编译不安装等开关。3. Visual Studio / MSVCWindows 用户有两条路打开 QuantLib.sln直接构建所需的配置/平台组合使用msbuild命令行驱动同一个解决方案。关键前提是确保 Boost 包含路径已配置。仓库在 .ci 目录维护了按 Visual Studio 版本区分的属性文件VS2017.props、VS2019.props、VS2022.props、VS2026.props等文档中提到的.ci/VS2022.props即其中之一其中还包含替代配置VS2022.alt.props与 Unity 构建属性.ci/Unity.props。此外CMake 侧对 MSVC 还有专门设计QL_TAGGED_LAYOUT默认在 MSVC 下开启会按 x64/mt/gd/sgd 等维度给库文件追加后缀见 CMakeLists.txt并在 Unity 构建时对测试目标追加/bigobj见 test-suite/CMakeLists.txt。4. 运行测试套件4.1 不同构建树下的调用方式# CMake 构建树在 build/ 下执行 ./test-suite/quantlib-test-suite --log_levelmessage # Autotools 构建仓库根目录执行 ./test-suite/quantlib-test-suite --log_levelmessage # CMake install 之后二进制可能已在 PATH 中 quantlib-test-suite --log_levelmessage # CTest 路径 ctest -V二进制统一命名为quantlib-test-suiteCMake 侧通过set_target_properties(... OUTPUT_NAME quantlib-test-suite)指定见 test-suite/CMakeLists.txtAutotools 侧则是bin_PROGRAMS quantlib-test-suite见 test-suite/Makefile.am。--log_levelmessage表示只打印普通消息级别以上的测试输出。CTest 与 CMake 深度集成add_test(NAME quantlib_test_suite COMMAND ql_test_suite --log_levelmessage)见 test-suite/CMakeLists.txt已将完整测试注册为 CTest 用例因此ctest -V等价于跑全量测试并显示详细输出。Autotools 侧则通过TESTS/TESTS_ENVIRONMENT机制注册见 test-suite/Makefile.ammake check即可触发。4.2 运行指定套件与单个用例QuantLib 的测试基于 Boost.Test套件名与用例名采用BOOST_AUTO_TEST_SUITE/BOOST_AUTO_TEST_CASE定义。例如在 test-suite/europeanoption.cpp 中定义了BOOST_AUTO_TEST_SUITE(EuropeanOptionTests)在 test-suite/europeanoption.cpp 中定义了用例testValues。因此可以精确过滤# 指定套件在 build/ 下执行 ./test-suite/quantlib-test-suite --log_levelmessage \ --run_testQuantLibTests/EuropeanOptionTests # 指定单个用例 ./test-suite/quantlib-test-suite --log_levelmessage \ --run_testQuantLibTests/EuropeanOptionTests/testValues在开发或排障时这种套件 → 用例的二级过滤能大幅缩短迭代周期——全量测试涵盖 test-suite/CMakeLists.txt 中 180 个测试源文件从americanoption.cpp到zigguratgaussian.cpp单跑一个用例通常只需数秒。4.3 并行测试 runner若构建时开启QL_ENABLE_PARALLEL_UNIT_TEST_RUNNER/--enable-parallel-unit-test-runner测试将通过 test-suite/paralleltestrunner.hpp 提供的并行 runner 执行利用多核 CPU 缩短总时长。注意它会引入shm_open等 POSIX 共享内存机制因此在非 Apple 的 *nix 上还要求链接rt库见 CMakeLists.txt。5. CI 现实检查工作流地图与触发规则5.1 核心验证工作流所有工作流位于 .github/workflows文档点名的核心验证文件均确认存在编译矩阵linux.yml、macos.yml、msvc.yml、cmake.yml代码质量tidy.ymlclang-tidy、headers.yml头文件自包含检查、filelists.yml构建清单一致性5.2 不在 PR 上运行的矩阵以下四个矩阵不在 pull request 上运行仅由每周schedulecron、workflow_dispatch或workflow_call触发linux-nondefault.ymllinux-full-tests.ymlmsvc-nondefault.ymlcmake-latest-runners.yml以.github/workflows/linux-nondefault.yml为例其on:块只有schedulecron: 0 0 * * 0、workflow_dispatch、workflow_call没有pull_request与文档描述完全一致。这类矩阵覆盖了编译器和 Boost 版本的广度如 GCC 8.3/Boost 1.72 到 GCC 15、Clang 7 到 Clang 21以及--enable-unity-build、--enable-openmp等非默认组合。但文档强调对可移植性敏感的改动仍需主动检查这些矩阵。四个工作流都接受workflow_dispatchAgent 可以在贡献者的 fork 中自行触发gh workflow run linux-nondefault.yml --repo fork --ref branch gh run list --workflowlinux-nondefault.yml --repo fork --limit 1使用纪律文档明确要求这些矩阵运行时间很长必须节约使用。Agent 在 dispatch 之前必须获得显式批准绝不能自作主张启动应优先阅读最近一次定时运行的结果只触发覆盖本次改动范围的那个工作流并在 PR 中标注该改动可能影响这些矩阵。5.3 非默认配置的本地替代验证远程矩阵真正独有的价值是编译器/Boost 版本广度 runner 镜像非默认的构建配置本身完全可以本地复现通常已经足够第 2 节的./configure标志Autotools第 1 节的对应QL_*CMake 变量第 3 节的 .ci 下的*.props文件MSVC例如linux.yml主矩阵在本地很难复现的是-stdc17/20/23/26四种语言模式各编译一遍、以及--enable-intraday、--enable-throwing-in-cycles等配置组合见.github/workflows/linux.yml但这些组合在本地跑一次./configure --enable-intraday make ./test-suite/quantlib-test-suite成本很低可先本地验证再决定是否触发远程矩阵。5.4 自动化工作流仓库还维护一批自动化工作流生成头文件、包含清单、命名空间、版权等它们会随时间变化generated-headers.yml、includes.yml、filelists.yml必须保持绿色——任何触碰头文件、文件清单的改动都要过这三关。此外还有copyrights.yml、namespaces.yml、misspell.yml等见 .github/workflows 完整目录。注意文档的表述头文件和文件清单的改动必须在generated-headers.yml、includes.yml、filelists.yml中保持绿色这呼应了开头三套构建系统都要登记新文件的硬约束。6. 信息源当上述内容疑似过期时去哪里核实文档明确给出验证链——当任何构建/CI 描述看起来与当前仓库不一致时应以以下文件为准工作流.github/workflows 下的linux.yml、linux-nondefault.yml、linux-full-tests.yml、macos.yml、msvc.yml、msvc-nondefault.yml、cmake.yml、cmake-latest-runners.yml构建配置CMakeLists.txt、CMakePresets.json、configure.ac测试工程test-suite/CMakeLists.txt、test-suite/Makefile.am代码风格.clang-format、.clang-tidy这四条源是单一事实来源选项默认值变了、工作流矩阵改了、测试注册方式调整了都应该从这些文件重新推导而不是依赖本文或.agents/build-and-test.md中的静态描述。附构建与测试速查表需求推荐做法对应仓库文件最快构建cmake --preset linux-gcc-ninja-release cmake --build build/linux-gcc-ninja-releaseCMakePresets.json经典构建./autogen.sh ./configure make -j 4configure.acWindows 构建打开QuantLib.sln或msbuild配置 Boost 路径QuantLib.sln、.ci全量测试./test-suite/quantlib-test-suite --log_levelmessage或ctest -Vtest-suite/CMakeLists.txt单用例测试--run_testQuantLibTests/EuropeanOptionTests/testValuestest-suite/europeanoption.cpp非默认配置验证本地复现./configure标志或QL_*变量必要时经批准后 dispatch 远程矩阵.github/workflows赞分享金融科技科学计算【免费下载链接】QuantLibThe QuantLib C library项目地址https://gitcode.com/gh_mirrors/qu/QuantLib点击查看免费下载相关推荐Terminal.Gui 构建与测试工作流实战指南从 dotnet restore 到 CI 全流程Terminal.Gui 构建与测试工作流实战指南从 dotnet restore 到 CI 全流程 Terminal.Gui 是一个面向 .NET 的跨平台UI组件跨平台桌面应用LibYAML 构建与集成指南从 autotools/CMake 构建到 H2O 配置解析实战LibYAML 构建与集成指南从 autotools/CMake 构建到 H2O 配置解析实战 LibYAML 是一个用 C 语言实现的 YAML 1.1 解后端网络ODS 升级与回滚机制bootstrap-upgrade 安全网深度解析ODS 升级与回滚机制bootstrap upgrade 安全网深度解析 ODSOpen Data Server是一个把你的 PC、Mac 或 LinuxAI 应用大模型本地部署RAGAI Agent后端语音上一篇A2A Chat Canvas 组件集成指南在 Angular 中构建 A2A A2UI 的聊天与画布界面下一篇gpui-kit VirtualList 虚拟列表指南用可变行高渲染十万级数据创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表