拓冰网站定制 
vcpkg 更新端口 vcpkg.json 版本号后如何重新生成 versions 版本数据库文件【免费下载链接】vcpkgC Library Manager for Windows, Linux, and MacOS项目地址: https://gitcode.com/GitHub_Trending/vc/vcpkg修改某个端口的ports/portname/vcpkg.json提升version或port-version之后如果不同步更新versions/目录下的版本数据库文件vcpkg 的 Validate version files 检查会直接报错且不会执行任何端口的构建。这篇文档基于本仓库内的 PR 提交清单、CI 失败模式参考和版本数据库脚本说明如何识别这个问题、重新生成版本数据库文件并确认修复生效。识别问题错误长什么样、涉及哪些文件文档记录的典型报错如下文档示例端口名和数字来自参考文档中的真实用例ports/arrow-adbc/vcpkg.json: error: arrow-adbc22 was not found in versions database versions/baseline.json: error: arrow-adbc is assigned 16, but the local port is 22 note: run vcpkg x-add-version arrow-adbc to add the new port version两个判断要点失败的任务是 Validate version files而不是 Test Modified Ports 等构建任务。报错信息末尾的note:行会直接给出应该执行的命令。根因是 PR 更新了端口在vcpkg.json中的版本号但没有重新生成版本数据库文件即versions/目录下的两个位置来源CI 失败模式参考versions/{端口名首字母}-/{端口名}.json记录该端口历史上每一次版本变更包含git-tree、version、port-version字段。仓库中的真实文件如 abcmake 版本文件{ versions: [ { git-tree: ee7b2ca269c0bbca7802c6750bc3555d750506a7, version: 6.4.0, port-version: 0 } ] }versions/baseline.json记录每个端口的基线条目即端口名 - { baseline: 版本, port-version: 数字 }。报错中 assigned 16, but the local port is 22 说的就是这里的port-version与vcpkg.json里的值对不上。另外注意这类失败不产生构建日志产物GitHub Actions 的 Check 作业也会因同一原因失败所以不要在找构建日志上浪费时间。重新生成版本数据库文件在工作目录为 vcpkg 仓库根目录./vcpkg可执行文件所在位置的前提下按改动范围二选一只改了一个端口的版本号时按报错note:行给出的端口名执行vcpkg x-add-version {portname}一次 PR 改动了多个端口或需要整体修复时用 PR 提交清单中给出的全量形式./vcpkg x-add-version --all两条命令的适用区别只在范围单端口命令只处理指定端口的版本数据库文件--all覆盖全部端口在只改一个端口的 PR 中用它不会造成问题但会重新检查整个versions/目录。PR 提交清单中端口更新检查表的一项原文是The version database is fixed by rerunning./vcpkg x-add-version --alland committing the result.即执行命令后必须把生成的文件改动一并提交只改vcpkg.json不提交版本文件等于没有修复。命令本身的工作原理可以对照 scripts/generatePortVersionsDb.py版本数据库文件由端口的 git 历史推导而来脚本对每个尚未生成版本文件的端口执行vcpkg x-history输出 JSON 到versions/对应目录。因此执行前确认你改动的vcpkg.json已经保存命令读到的才是新内容。验证修复是否生效按文档给出的口径核对三点修改后的版本文件里每个文件恰好新增一条版本记录。这是 PR 提交清单中明确要求勾选的检查项Exactly one version is added in each modified versions file.。执行命令后用git diff查看versions/下的改动versions/{首字母}-/{端口名}.json的versions数组应只比之前多一条记录versions/baseline.json中该端口的baseline/port-version与新版本号一致。本地不再复现报错。修改前那种was not found in versions database或baseline.json与本地端口版本不一致的错误消息应消失——这正是 Validate version files 任务检查的内容。CI 上 Validate version files 任务通过并且后续才会进入端口构建阶段。CI 报告模板中对该类问题的结论与本文一致portnameN was not found in versions database的修复方式就是vcpkg x-add-version portname且该失败属于版本校验问题不是构建回归。边界与说明x-add-version是带x-前缀的内部命令仓库文档中只在 PR 清单和 CI 参考里出现版本机制专题文档 本身已迁移到外部 Microsoft Learn 站点本仓库内不提供该命令的完整参数说明本文只给出上述两种文档中实际出现的用法。本文针对已存在的端口更新版本号这一触发路径。新增端口时同样需要重新生成版本数据库文件PR 清单的新端口检查表包含同一条x-add-version --all项但新端口还涉及基线去索引等 CI 侧处理不在此展开。生成文件后要提交但不要把x-add-version产生的无关versions/改动混入与本次端口无关的历史修复——清单要求exactly one version is added in each modified versions filediff 中每个版本文件只应多出一条记录。【免费下载链接】vcpkgC Library Manager for Windows, Linux, and MacOS项目地址: https://gitcode.com/GitHub_Trending/vc/vcpkg创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 vcpkg 更新端口 vcpkg.json 版本号后如何重新生成 versions 版本数据库文件？
vcpkg 更新端口 vcpkg.json 版本号后如何重新生成 versions 版本数据库文件【免费下载链接】vcpkgC Library Manager for Windows, Linux, and MacOS项目地址: https://gitcode.com/GitHub_Trending/vc/vcpkg修改某个端口的ports/portname/vcpkg.json提升version或port-version之后如果不同步更新versions/目录下的版本数据库文件vcpkg 的 Validate version files 检查会直接报错且不会执行任何端口的构建。这篇文档基于本仓库内的 PR 提交清单、CI 失败模式参考和版本数据库脚本说明如何识别这个问题、重新生成版本数据库文件并确认修复生效。识别问题错误长什么样、涉及哪些文件文档记录的典型报错如下文档示例端口名和数字来自参考文档中的真实用例ports/arrow-adbc/vcpkg.json: error: arrow-adbc22 was not found in versions database versions/baseline.json: error: arrow-adbc is assigned 16, but the local port is 22 note: run vcpkg x-add-version arrow-adbc to add the new port version两个判断要点失败的任务是 Validate version files而不是 Test Modified Ports 等构建任务。报错信息末尾的note:行会直接给出应该执行的命令。根因是 PR 更新了端口在vcpkg.json中的版本号但没有重新生成版本数据库文件即versions/目录下的两个位置来源CI 失败模式参考versions/{端口名首字母}-/{端口名}.json记录该端口历史上每一次版本变更包含git-tree、version、port-version字段。仓库中的真实文件如 abcmake 版本文件{ versions: [ { git-tree: ee7b2ca269c0bbca7802c6750bc3555d750506a7, version: 6.4.0, port-version: 0 } ] }versions/baseline.json记录每个端口的基线条目即端口名 - { baseline: 版本, port-version: 数字 }。报错中 assigned 16, but the local port is 22 说的就是这里的port-version与vcpkg.json里的值对不上。另外注意这类失败不产生构建日志产物GitHub Actions 的 Check 作业也会因同一原因失败所以不要在找构建日志上浪费时间。重新生成版本数据库文件在工作目录为 vcpkg 仓库根目录./vcpkg可执行文件所在位置的前提下按改动范围二选一只改了一个端口的版本号时按报错note:行给出的端口名执行vcpkg x-add-version {portname}一次 PR 改动了多个端口或需要整体修复时用 PR 提交清单中给出的全量形式./vcpkg x-add-version --all两条命令的适用区别只在范围单端口命令只处理指定端口的版本数据库文件--all覆盖全部端口在只改一个端口的 PR 中用它不会造成问题但会重新检查整个versions/目录。PR 提交清单中端口更新检查表的一项原文是The version database is fixed by rerunning./vcpkg x-add-version --alland committing the result.即执行命令后必须把生成的文件改动一并提交只改vcpkg.json不提交版本文件等于没有修复。命令本身的工作原理可以对照 scripts/generatePortVersionsDb.py版本数据库文件由端口的 git 历史推导而来脚本对每个尚未生成版本文件的端口执行vcpkg x-history输出 JSON 到versions/对应目录。因此执行前确认你改动的vcpkg.json已经保存命令读到的才是新内容。验证修复是否生效按文档给出的口径核对三点修改后的版本文件里每个文件恰好新增一条版本记录。这是 PR 提交清单中明确要求勾选的检查项Exactly one version is added in each modified versions file.。执行命令后用git diff查看versions/下的改动versions/{首字母}-/{端口名}.json的versions数组应只比之前多一条记录versions/baseline.json中该端口的baseline/port-version与新版本号一致。本地不再复现报错。修改前那种was not found in versions database或baseline.json与本地端口版本不一致的错误消息应消失——这正是 Validate version files 任务检查的内容。CI 上 Validate version files 任务通过并且后续才会进入端口构建阶段。CI 报告模板中对该类问题的结论与本文一致portnameN was not found in versions database的修复方式就是vcpkg x-add-version portname且该失败属于版本校验问题不是构建回归。边界与说明x-add-version是带x-前缀的内部命令仓库文档中只在 PR 清单和 CI 参考里出现版本机制专题文档 本身已迁移到外部 Microsoft Learn 站点本仓库内不提供该命令的完整参数说明本文只给出上述两种文档中实际出现的用法。本文针对已存在的端口更新版本号这一触发路径。新增端口时同样需要重新生成版本数据库文件PR 清单的新端口检查表包含同一条x-add-version --all项但新端口还涉及基线去索引等 CI 侧处理不在此展开。生成文件后要提交但不要把x-add-version产生的无关versions/改动混入与本次端口无关的历史修复——清单要求exactly one version is added in each modified versions filediff 中每个版本文件只应多出一条记录。【免费下载链接】vcpkgC Library Manager for Windows, Linux, and MacOS项目地址: https://gitcode.com/GitHub_Trending/vc/vcpkg创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考