Skip to content

Latest commit

 

History

History
92 lines (67 loc) · 5.31 KB

File metadata and controls

92 lines (67 loc) · 5.31 KB

第六轮生态复核:工具平面的目标轴

2026-09-07。本轮把 mcpp.toml 里未成文的组织规律写成 SPEC-004,并补上规则暴露出的 唯一结构性缺口:工具平面只有宿主轴。发布 mcpp 2026.9.6.4

设计文档:.agents/docs/2026-09-07-mcpp-toml-unified-semantics-design.md。 规范:docs/specs/manifest-semantics.md

1. 改了什么

[target.<selector>.xlings.workspace][target.<selector>.feature-xlings.<f>] 被接受,按目标解析,形状与既有的 [target.<selector>.build][target.<selector>.feature-deps.<f>] 相同。零新词表,零新 section,没有任何已发布的 键被改名,既有写法全部保持原义。

四处拒绝,每一处拦的都是"会消失在沉默里"的陈述:

拒绝 理由
selector 之下再写平台键 同一个条件写了两遍,两处可以不一致
selector 命名目标侧层 时序:层由依赖解析回答,而那一遍在工具供给之后、每个包的 build.mcpp 之后
selector 之下写 subos 一个工程只有一个环境,不是每个目标一个
发布期的目标轴条目(报告,不拒绝) 描述符按平台分块,而 selector 不是平台

两条轴同时命名一个包时,去重按而非按地址(xim:glibcxim:glibc@2.40 是 同一次安装的两个地址),[target.<selector>] 一侧胜出并报告。

2. 判据

# 判据 结果
V1 SYCL 示例把四条目标输入移到目标轴后仍构建,设备编译的 C 库搜索链里生态在宿主之前 通过。五条载荷全部供给;check_device_c_library.shecosystem at position 2, first host path at 8
V2 目标轴按目标解析,宿主轴不随目标改变 通过。tests/unit/test_target_xlings_axis.cpp 把同一份 manifest 按两个不同目标各解析一次
V3 两处条件被拒绝 通过(同一文件 + 沙箱 C 段)
V4 既有 manifest 一个字不改仍构建 通过。顶层解析路径未改动;CI 的 examples job 在干净检出上构建全部示例
V5 层谓词被拒绝 通过。e2e 619,且旧引擎上同一份工程构建成功
V6 按包去重 通过(单测)

V2 是核心判据,而它不是一次构建。 两条轴在非交叉时恰好一致,所以"示例构建成功" 对这条差异零信息量。判据因此落在"同一份 manifest 按两个不同目标解析出不同的条目集合" 上——这个测量在一台机器上、不需要交叉工具链就能做。把接线摘掉后七条断言里五条当场 变红,剩下两条正是宿主轴的回归断言。

3. 实现过程中发现的两个缺陷

3.1 层谓词会让工具被声明却永远装不上

本文原本的 cfg(accelerator = "vulkan") 示例是错的。层由依赖解析回答,命名层的 谓词被推迟到第二遍合并,而那一遍跑在工具供给之后。在那里被接受的条目产生的失败形态 是最坏的一种:构建成功,工具就是不在。改为拒绝,并在消息里给出两条出路。

e2e 619 两侧都测:新引擎拒绝,旧引擎上同一份工程构建成功——这正是它要挡住的形态。

3.2 判据读了一份不是自己写的图(mcpp-plugins#5)

tools/check_device_c_library.sh 构建 fixture 之后按 glob 顺序取第一个声明设备动作的 build.ninja。构建目录按指纹命名,所以一棵构建过多次的树里每个配置、每个引擎与载荷 版本各有一个;glob 的第一个不是这次写的那个。

实测:它报"设备编译器的搜索列表上没有生态 C 库",而它读的那份图是前一天由 mcpp.plugins 0.2.0 产生的——正是这个检查要守护的修复之前的版本;同一条命令刚写下的 那份图两个 -isystem 都在。CI 上不可见,因为检出是干净的。

修法是构建前删掉 target/:检查的对象必须由检查自己产生。

4. 生态状态

仓库 变更 状态
mcpp SPEC-004 目标轴 + 四处拒绝 + docs/specdocs/specs PR #581 合入,main 九个 workflow 全绿
mcpp-plugins 判据读自己写的图 PR #5 合入,main 绿
mcpp-index 无需变更 ——
xim-pkgindex 版本 bump PR #774 合入,三行 ["latest"] 全指 2026.9.6.4

生态包本轮不改写法。 目标轴要求 mcpp 2026.9.6.4,而已发布的包声明的引擎下界低于 该版本;让一个包的诊断推荐旧引擎会拒绝的写法,就是把升级悬崖搬进使用者的工程。这条 规则已写进 SPEC-004 §4.3。

5. 发布与真实验证

v2026.9.6.4:四个平台载荷 + 密封的 mcpp-release.json,GitHub 与 GitCode 两处 200 且字节数一致(镜像完整,不需要本地 gtc 补资源)。索引 sha256 由重新下载并 重算核对,与 PR #774 逐字符一致。Publish Index Artifact 在索引 main 上绿——那是 xlings 真正消费的那一层。

沙箱验证 .agents/docs/2026-09-07-round6-verify.sh,跑在 verify-964 上,对着已发布 的二进制,六段全过。

其中 B 段是唯一能问出"目标轴条目真的被装上了吗"的地方:它先读出沙箱的 registry 里 没有 xim:shaderc,再由目标轴把它装进来。任何构建过这个包的机器上,载荷已经在了, 答案与轴读没读无关——这正是本轮引擎缺陷(依赖的 [feature-xlings] 在其 build.mcpp 之后才被供给)当初藏身的形状。