性能测试【免费下载链接】benchmarkA microbenchmark support library项目地址https://gitcode.com/gh_mirrors/benchmark5/benchmark点击查看免费下载本文基于 docs/releasing.md 中维护者定义的完整发布清单逐环节拆解 Google Benchmark 项目从验证构建到发布标签再到Python Wheel 自动构建的整个版本发布链路并结合 CMakeLists.txt、MODULE.bazel、pyproject.toml 等仓库文件说明每个步骤背后的工程原因。读完后你将掌握一个同时维护 CMake、Bazel 双构建系统且附带 Python 绑定项目的标准发布操作以及为什么版本要提前写进配置文件为什么 GitHub 的轻量标签必须改写成注释标签这类关键细节。一、发布前的总体准备docs/releasing.md 定义的第一个前提是确保当前处于main分支并且已与远端 HEAD 完全同步然后确认项目可以构建且测试能够运行。文档中给出了一个加速全量测试运行的实用技巧parallel -j0 exec ::: test/*_test这条命令配合 GNUparallel以全部可用核心-j0并行执行test/目录下编译出的各个*_test测试二进制。对照仓库中的测试目录 test/其中每个*_test.cc源文件如 test/basic_test.cc、test/filter_test.cc 等都会编译为一个独立的可执行程序因此test/*_test恰好覆盖全部功能测试入口。文档明确这一手段至少能确保所有测试都能通过——这是发布动作的第一道质量门禁任何一项测试失败都应阻塞后续流程。二、准备发布说明Release Notes发布说明的来源是上一个版本标签到 HEAD 之间的提交列表文档给出的命令为git log $(git describe --abbrev0 --tags)..HEAD其工作原理分两步git describe --abbrev0 --tags输出距离 HEAD 最近的一个标签名即上一个发布版本例如v1.8.3外层的git log 上一个标签..HEAD列出自该标签之后到当前 HEAD 的所有提交。维护者随后从这份提交列表中挑选最有意义的条目Pick the most interesting写入发布说明。这一做法保证了 Release Notes 与实际交付的代码差异严格对应不遗漏、不虚构。三、关键版本提交同步更新 CMake 与 Bazel 两处版本号发布流程中最容易被忽略、但影响面最大的一步是在创建发布之前先创建最后一个提交把保存在CMakeLists.txt和MODULE.bazel中的版本号更新为即将发布的版本。3.1 两个必须同步的版本位置文档原文示例project (benchmark VERSION 1.8.0 LANGUAGES CXX)module(name com_github_google_benchmark, version1.8.0)对照当前仓库的实际内容这两处分别位于CMakeLists.txtproject (benchmark VERSION 1.8.4 LANGUAGES CXX)MODULE.bazelmodule(name google_benchmark, version 1.8.4)两处分别服务不同的消费渠道CMakeLists.txt中的project(... VERSION ...)是 CMake 安装包的版本来源。下游通过find_package(benchmark REQUIRED)见 README.md 中的 Usage with CMake 一节导入库时benchmark_VERSION就取自这里MODULE.bazel中的version是 Bazel bzlmod 体系的模块版本声明Bazel 模块用户在锁定依赖版本时以此为准。根目录的 WORKSPACE.bzlmod 仅标记了 Bazel workspace 的根真正的依赖与版本信息都集中在MODULE.bazel中。文档特别解释了这一步的必要性This version will be used if benchmark is installed from the archive youll be creating in the next step.也就是说从 GitHub Release 页面下载的是纯源码压缩包不含.git目录此时只能依赖配置文件里写死的版本号。仓库源码印证了这一机制CMakeLists.txt 中有一段版本探测逻辑——构建时先通过GetGitVersion模块读取 git 标签得到GIT_VERSION当探测不到GIT_VERSION为占位值v0.0.0典型场景就是从源码归档构建、没有 git 历史时回退使用project()命令中的benchmark_VERSION作为VERSION。随后代码还会对版本号做归一化处理去掉v前缀、把vX.Y-距离数-hash形式的描述式版本转成X.Y.Z最终用于派生库的SOVERSION# If no git version can be determined, use the version # from the project() command if (${GIT_VERSION} STREQUAL v0.0.0) set(VERSION v${benchmark_VERSION}) else() set(VERSION ${GIT_VERSION}) endif()因此如果发布前忘记提交这次版本更新归档安装出来的库版本就会停留在上一个版本属于典型的发布事故。这也是文档把版本提交安排在创建 release之前、并要求它是最后一个提交one last commit的原因。3.2 操作要点小结切换到main并同步到 HEAD确认构建与全部测试通过用git log $(git describe --abbrev0 --tags)..HEAD起草发布说明提交版本号更新同时修改CMakeLists.txt的project(... VERSION ...)与MODULE.bazel的module(... version ...)两处数值必须一致进入标签与 Release 环节下一节。四、创建 GitHub Release并将轻量标签改写为注释标签文档指出通过 GitHub 界面创建 release 时Git 层面实际产生的是一个轻量标签lightweight tag——它只是一个指向 commit 的普通引用不携带标签者、时间戳和标签消息。为了保证后续工具链尤其是基于标签的版本推导系统能拿到完整元数据需要把它改写为注释标签annotated tag。文档给出的完整命令序列git pull --tags git tag -a -f tag tag git push --force --tags origin逐步解读git pull --tags先把远端刚创建的轻量标签拉取到本地git tag -a -f tag tag-a表示创建注释标签-f表示强制覆盖已有的同名轻量标签。这里用同名指向同名的写法等价于原地把轻量标签升级为注释标签commit 指向不变但引用对象由 commit 变为 tag 对象git push --force --tags origin由于远端已存在同名轻量标签普通推送会被拒绝因此必须--force强推标签引用。这一步不能省略它直接关系到最后一步 Python Wheel 的版本推导是否正确——下一节会解释。五、确认 Build and upload Python wheels 工作流完成本仓库为 Python 提供了基于 nanobind 的绑定见 bindings/python/google_benchmark/BUILD 中的nanobind_extension目标并配套了发布到 PyPI 的自动化流程。docs/releasing.md的最后一项要求确认 Build and upload Python wheels 这一 GitHub Actions 工作流运行完成如果它没有自动触发需要手动运行关键注意点文档原文以 IMPORTANT 标出手动重新运行工作流时务必在 GitHub Actions 页面的 Run workflow 选项卡中选择刚创建的tag作为 workflow version否则工作流会基于错误的提交/标签构建产出的 Wheel 版本号将是错的。这一标签决定 Wheel 版本的机制在仓库配置中可以找到直接证据pyproject.toml 声明dynamic [readme, version]即包版本是动态计算而非写死的pyproject.toml 的构建系统依赖setuptools-scm[toml]该工具正是从git 标签推导版本号的——这解释了为什么第四节的轻量标签改注释标签必不可少setuptools-scm读取标签信息时依赖完整的标签元数据且版本数值必须来自本次发布的确切标签安装后绑定包通过 bindings/python/google_benchmark/version.py 中的importlib.metadata.version(google-benchmark)对外暴露版本因此工作流构建的 Wheel 版本号就是 PyPI 上用户看到的最终版本pyproject.toml 同时声明了requires-python 3.8classifiers覆盖 Python 3.83.12Wheel 的构建与校验应以这些约束为前提。验证环节完成后一次发布才算真正结束C/C 用户通过源码归档 find_package/add_subdirectory消费新版本Bazel 模块用户通过 bzlmod 锁定新版本Python 用户通过 PyPI 安装新 Wheel三条渠道的版本号完全一致。六、发布检查清单速查将 docs/releasing.md 的完整流程整理为可执行的检查清单步骤命令 / 操作说明1. 分支确认git checkout main git pull确保在 main 且同步到 HEAD2. 构建与测试构建项目parallel -j0 exec ::: test/*_test全部测试必须通过3. 起草发布说明git log $(git describe --abbrev0 --tags)..HEAD取上一标签到 HEAD 的提交列表挑选关键条目4. 版本提交更新 CMakeLists.txt 的project(... VERSION ...)与 MODULE.bazel 的version必须提交且数值一致供无 git 环境的归档安装使用5. 创建 ReleaseGitHub 界面创建 release实际生成轻量标签6. 升级为注释标签git pull --tagsgit tag -a -f tag taggit push --force --tags origin保证标签元数据完整供 setuptools-scm 等工具推导版本7. Wheel 工作流确认 Build and upload Python wheels 运行完成手动重跑时必须在 Run workflow 中选择新tag作为 workflow version七、适用前提与注意事项适用版本范围当前仓库CMakeLists.txt与MODULE.bazel中的版本为1.8.4文档示例中的1.8.0为撰写时的占位版本实际操作时以即将发布的下一个版本号替换两处数值即可。版本探测机制的前提CMakeLists.txt 中git 标签优先、project()版本兜底的双轨机制意味着带完整 git 历史的克隆仓库构建时版本由标签决定只有归档/子模块等无标签场景才回落到project()版本。发布前提交版本号的收益主要体现在后者。强制推送的安全性git push --force --tags仅影响标签引用tag ref不影响main分支的 commit 历史但会覆盖远端同名标签操作前应确认标签确实指向本次发布提交。Bazel 消费方模块名与版本以 MODULE.bazel 为准google_benchmark当前1.8.4该文件还声明了bazel_skylib、rules_cc、googletest等构建依赖发布时仅需改动其中的version字段不应连带改动依赖声明。八、总结Google Benchmark 的发布流程看似只是几条命令实则串联了三条版本消费渠道CMake 归档安装、Bazel bzlmod、PyPI Wheel和一套完整的质量门禁。其设计要点可以概括为先验证构建全量测试、再定版双配置文件同步提交保证归档可用、后打标注释标签保证元数据完整、最后验渠道Wheel 工作流绑定正确标签。理解了GetGitVersion的兜底逻辑与setuptools-scm的标签驱动机制之后文档中每一步为什么必须这样做就有了清晰的源码级依据。赞分享性能测试【免费下载链接】benchmarkA microbenchmark support library项目地址https://gitcode.com/gh_mirrors/benchmark5/benchmark点击查看免费下载相关推荐如何3步掌握AMD处理器调试硬件性能调优完整指南如何3步掌握AMD处理器调试硬件性能调优完整指南 您是否曾为AMD Ryzen处理器性能无法完全释放而苦恼是否想要像硬件工程师一样深度掌控您的处理器却苦于性能测试开发工具最完整指南notepad--版本标签管理与Git发布全流程解析最完整指南notepad 版本标签管理与Git发布全流程解析 作为一款支持Windows/Linux/Mac平台的国产文本编辑器notepad 致力于提供跨桌面应用开发者必看battleforthenet-widget源码解析与扩展指南开发者必看battleforthenet widget源码解析与扩展指南 battleforthenet widget是一款用于支持网络中立性的开源工具开发上一篇Stable Diffusion WebUI Forge批量图像处理效率提升10倍的秘诀下一篇imgui-rs高级功能探索表格、拖拽、停靠等企业级特性创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考