v0.0.102

四条 issue 一个批次:#261 windows 命令行长度、#257 clang 依赖跟踪缺口、#258 条件段表达力、#254 host/target 双轴不自洽。贯穿主线是同一决策不许两处推导,以及本批次新立的第二条不变量失败必须响,不许静默降级。设计见 .agents/docs/2026-07-22-v0.0.102-batch-254-261-design.md,issue 裁决见 .agents/docs/2026-07-22-issue-triage-254-261.md。

修复

• windows scan-deps 撞 8191 字符上限(#261):clang 扫描规则此前用 shell 重定向产出 P1689 JSON,ninja 在 windows 走 CreateProcess 不解释 >,于是整条命令被 cmd /c 包裹——而 cmd.exe 的命令行上限是 8191,只有 CreateProcess 的 1/4。改用 clang-scan-deps -o(LLVM 17+,两个自带工具链均实测可用),重定向与包裹一并消失,与 GCC 的 -fdeps-file=、MSVC 的 /scanDependencies 三条分支形态统一。cmd /c 自此在全仓 ninja 规则中绝迹。
• windows 编译/扫描命令行无长度兜底(#261):local_include_flags() 每依赖一个 -I、无上界,而 cxx_module/cxx_object/c_object/asm_object/cxx_scan 全部内联该载荷;扫描命令包住编译命令,只是恰好先炸。把 #247 给链接规则的 response file 推广到所有携带无界载荷的规则(gcc/clang 驱动与 cl.exe 均展开 @file,clang-scan-deps 会把 -- 之后的 @file 透传给驱动;NASM 因为拼写是 -@ file 而排除)。顺带把 escape_flag_path 改用 generic_string()——这是 #247 那个坑往下一层:response file 内容按 GNU 文法分词,反斜杠是转义符,windows 的 -I 路径一旦离开命令行就会丢分隔符。POSIX 逐字节不变。
• clang 路径 purview #include 不触发重建(#257):编辑模块接口 purview 内 #include 的文件后,构建静默复用陈旧 BMI,导入方对着旧接口编译——最差的一类失效,错误结果看起来像一次正常的增量构建。根因是 0.0.97 把两个决策捆在一个谓词里:是否发 depfile 与 是否剥离 GCC -fmodules 附加的 reversed make-rules。实测两个自带工具链,clang 的 module-TU depfile 就是一条普通规则(x.o: x.cppm ops.inc),没有任何需要过滤的东西——当年那道闸在防一个不存在的形状,代价是把与它捆在一起的正确性契约一起关掉了。现拆为 posixDepfile(所有 POSIX 非 MSVC)与 needsGnuModuleFilter(仅 GCC)。同时补上同一处不对称的另一半:c_object/asm_object 此前在任何工具链上都没有 depfile。windows 非 MSVC(mingw gcc / 托管 clang)仍无 depfile(GCC 过滤器依赖 awk),但现在经 diag::degraded 明确上报影响,不再静默。
• xpkg per-OS 段按宿主而非目标拼接(#254):per-OS 段的 sources/flags/deps 与 xpm 版本/资产表全部按 xpkg_platform 这个编译期宿主常量选取,而 [target.'cfg(...)'] 按解析后的目标求值——同一决策两处推导。交叉编译时依赖包因此被拼进宿主那条腿。原生构建 host == target 恰好掩盖了它,所以三平台 CI 从未发现。

新增

• mcpp::diag 统一降级/告警通道:degraded() 强制填写 impact——作者必须回答"用户会因此遭遇什么",而这正是每一个静默降级 bug 当年缺的那句话。记录按整条载荷去重、报告即渲染(告警与 ui::status 的交织顺序、以及提前返回前已报内容都不变),--strict 提升策略收敛到单点(此前在 prepare.cppm 里 copy-paste 了 5 处)。告警内容首次可单测。prepare.cppm 的 8 处裸 println(stderr, "warning: ...") 已迁入;渲染仍走 ui::warning,输出逐字节不变。
• [target.'cfg(...)'.build] 支持 per-glob flags 与 include_dirs(#258,xpkg target_cfg 同步):此前 sources 可按 OS 条件化而 flags 不能,于是一份覆盖三 OS 的 manifest 必须让每个 OS 都看到另外两个 OS 的 flag 条目,而它们按构造必然零命中。vendored-opencv 移植为此付出 703 个 stub 文件(唯一用途是给 windows TU 制造 OS-唯一路径好让全局 flag 表 key 上去)、32 条指向它们的 glob,以及每次构建 ~23 条结构性死 glob 告警。条件条目追加在 base 之后,GNU last-wins 使撤销可表达(windows 需要 -UHAVE_UNISTD_H 对抗 base 的 -D,而无条件覆盖层做不到——-U 反条目自身也需要按 OS 条件化,递归回同一缺口)。死 glob 告警由结构消除:不匹配当前 OS 的条目根本不进 globFlags,与 #253 在 feature 轴上的做法同构;issue 里提的 optional = true 逃生口明确不做,那会成为第二套抑制机制。
• mcpp.platform.axis:host / target 两轴成为不同类型(#254):互不可转换,且都不能由裸字符串构造;API 声明自己要哪一轴,调用点必须指名自己给的是哪一轴。synthesize_from_xpkg_lua 的平台参数去掉宿主默认值改为必填——静默默认正是这个 bug 得以存活的方式。三段 triple 与 xpkg 的词汇差异("macos" vs "macosx")收进 TargetPlatform::for_os。分类:依赖包 manifest 合成与版本/资产选择走 target;工具链版本列举走 host(其注释本就写明了理由);--all-os lint 走刻意起得别扭的 for_lint_of()。
• BuildInputs 类型(#258 的架构面):cfg 轴与 feature 轴此前各自手挑可条件化的字段子集,且挑得不一样(cfg 拿 cflags/cxxflags/ldflags/sources,feature 拿 sources/defines/flags)。"哪些构建输入可被条件化"这一决策被提炼成一个类型而非一张要靠人记得更新的表。入选判据两条:合并语义是追加;消费点在条件合并之后。据此排除选型轴(target 用来选定 triple,而谓词要靠该 triple 求值——构造性循环)与策略标量(需 last-wins,是另一场设计);generatedFiles 因为是写磁盘的副作用动作而非输入、featureDefines 因为是沿 Public 边传播的接口贡献而非私有构建输入,各自按范畴排除。BuildConfig 以继承方式承载(该字段在 ~150 处被读,嵌套只会是 150 次无收益的机械改动),ConditionalConfig 则嵌套——保证需要落在那里。合并收敛为单一 append(BuildInputs&, const BuildInputs&)。
• #256 clang 模块运算符模板 canary + 文档:mcpp 侧无缺陷(--precompile 成功,崩溃在 clang 前端的导入侧),但 mcpp 自带 LLVM,且该 hazard 正落在本项目推荐的模块包模式上。文档给出可操作规则(导出的运算符模板,所有模板参数应由第一个实参绑定;否则改为对整个推导操作数类型建模)与可直接套用的改写范式。e2e 150 是状态 canary 而非通过/失败契约:期望表记录 LLVM 20-22 崩、18-19 正常,一旦现实与期望不符即失败——未来某次 clang bump 修好它与再弄坏它同样是需要被看见的信号。

备注

• 新增不变量写入批次总账:任何"因条件不满足而少做一步"的分支,必须要么返回错误,要么经 diag::degraded 上报;log::debug/log::verbose 不算用户可见;丢弃 std::expected 返回值视为缺陷。
• #254 的覆盖是单测级:per-OS 段按 target 选段、host==target 逐字节不变、轴类型互不可转,三条单测锁定;原计划的"cross 腿消费带 per-OS 段的 xpkg dep"e2e 未落地(需要 e2e 侧先有"复用宿主 registry + 本地索引 + 预置 payload"的夹具,临时 MCPP_HOME 会触发整套交叉工具链重装),记为已知缺口。
• e2e 新增 148(64 个 include dir 的宽 include 表,POSIX 验内联形态、windows 验 response file)、149(条件段 per-glob flags 四象限:命中生效/覆盖 base 的 removal/非命中零告警/真死 glob 仍告警)、150(#256 canary);118 去掉 # requires: gcc 并加 clang 腿。
• 未包含:#259(根因在 xlings 侧的 dep 静默丢弃,调查结论已发 issue 评论;mcpp 侧另发现 sysroot 兜底是死代码——resolve_xpkg_path("xim:glibc") 缺版本必然失败且两处都丢弃返回值——一并另行安排);manifest 未知键策略五处不一致(#263,有兼容性面,与 #258 无依赖)。

v0.0.101

#253:feature 模型两缺口收口——per-feature per-glob flags + per-OS features 语义锁定,解锁 compat.opencv dnn off-linux 腿并消除 feature-off 构建的死 glob 告警。设计见 .agents/docs/2026-07-20-issue-253-feature-flags-and-per-os-features-design.md。

新增

• features.<name>.flags(#253):feature 级 per-glob 编译旗标,与 [build].flags 共用同一 entry 文法(glob 必填 + cflags/cxxflags/asmflags/defines),xpkg 与 mcpp.toml 双文法一数据模型(共享解析 helper)。激活时折入既有 globFlags 单一漏斗(scanner 匹配/per-TU 落旗标/死 glob 告警/fingerprint 四个下游零改动),追加在 base 规则之后、feature 按名序,"last flag wins" 使 feature 规则可覆盖 base;折入点在 includeDevDeps 门外(0.0.94 双路径不变量)。私有 per-TU、不传播(与接口开关 defines 的语义分界)。feature off 时规则不存在 → opencv mlas 一类"结构性必死 glob"的告警自然消失;feature on 而 glob 空仍告警,且文案点名归属 feature(features.<f>.flags glob '...' matched no source file)。TOML 侧 [[features.<name>.flags]] AOT 拼写同步进 #227 封闭文法 allowlist(features.*.flags 通配段)。
• per-OS features 语义锁定(#253):mcpp.<os> 段的文本拼接 additive overlay 本就覆盖 features 键——同名 feature 逐子键 append(中性段在前、OS 段在后),per-OS 段可注册 OS-only feature;现以单测(逐 OS osOverride)+ e2e 锁死并写入文档,配合 features.<f>.flags 构成 opencv dnn 的 common/delta 形态(中性段放跨平台公共载荷,per-OS 段放 mlas x86 / NEON 差集与其旗标)。

修复

• 依赖包 per-glob flags 此前不入 per-package fingerprint:canonical_package_build_metadata 只序列化 cflags/cxxflags/ldflags/genfiles,globFlags 靠"descriptor 随版本冻结"间接成立;feature 折入使该向量随构建变化,现与根侧同款全量有序序列化(globflags:/gc:/gxx:/gas:/gd:)。

备注

• e2e 新增 146(feature flags 四象限 + 死 glob 告警消除/点名 + 私有不传播对照)/147(per-OS features 端到端,宿主段生效、非宿主段投毒不可见);单测新增 xpkg/TOML 解析与 per-OS 合并锁定。host/target 轴缺陷(per-OS 拼接键=宿主常量,交叉编译选段错误)另开 issue 跟踪,不入本版。

v0.0.100

大型源码直编包(ffmpeg/opencv 级,数千 TU)全平台化批次:#247/#248/#249 平台三修 + 增量构建修复 + build.mcpp 指令面补全(P1)。设计见 .agents/docs/2026-07-19-large-source-pkg-platform-fixes-and-buildmcpp-generation-design.md。

修复

• windows driver-style 链接命令行溢出(#247):gnu 方言(g++/clang++ 作链接驱动——windows 托管 clang-MSVC 即此)的 cxx_link/cxx_archive/cxx_shared 此前内联 $in,数千对象直接溢出 CreateProcess 32 KiB 上限。现 windows 上 driver-style 也走 response file;两方言分支收敛为单一 link_rule 发射器(msvc 规则文本逐字节不变),POSIX 保持内联零变化。配套:ninja 节点名统一 generic_string() 正斜杠——rsp 内容按 GNU 文法分词,反斜杠是转义符(obj\cli.o 会被吃成 objcli.o)。
• macOS dep/root build.mcpp 收不到 G3 契约环境(#248,launcher-unify):非 Linux 的 capture_exec 走 shell 字符串拼接,ENV… cd <cwd> && bin 里 env 只绑给 cd(全仓唯一 env+cwd 双非空调用点恰是 build.mcpp)。现 macOS 与 Linux 同走 posix_spawn 直启路径(child-only env + addchdir_np,environ 经 _NSGetEnviron() portable-correct),顺带消掉 macOS 的 shell quoting/注入面。windows shell 回退补 cd /d(跨盘符)。
• generated_files 每次构建无条件重写毁增量:materialize 此前不比内容直接写,mtime 抖动令 ninja 把 include 该头的全部 TU 判脏——冻结快照包(config.h × 数千 TU)每次 build 都全量重编。现内容逐字节相同即跳写(变更检测本就由指纹负责)。
• xpkg feature 表未知子键(如 features.X.include_dirs)此前静默吞掉,现进 xpkgUnknownKeys 走统一告警面。

新增

• [build] include_dirs_after → -idirafter(#249):排在工具链系统目录之后搜索的 include 目录(descriptor/xpkg 与 mcpp.toml 双文法、* tarball 根 glob、沿 Public/Interface 边传播且不升级为 -I)。治大小写不敏感 macOS 上依赖源根 VERSION 顶替 libc++ <version> 一类系统头遮蔽;-isystem 不解此症(仍先于默认系统目录)。方言降级单点收敛:cl.exe → 末尾 /I,NASM 单元 → 普通 -I(NASM 会把 -idirafter<p> 误吞成 -i dirafter<p>)。附带统一主工程 include 路径的 glob 展开(此前与 dep 路径两套推导)。
• build.mcpp 指令面补全(P1,0.0.100+):mcpp:source=(选既有 payload 源入编译集,generated= 的"绝对路径灰色用法"正名)、mcpp:include-dir= / mcpp:include-dir-after=(私有 include,Cargo 纪律不进公共接口;typed 通道享方言降级);typed import mcpp; 同步 source()/include_dir()/include_dir_after()。契约环境拆分 MCPP_TARGET_OS/ARCH/ENV(免手撕三元组)。root build.mcpp 后移至依赖解析之后,与 dep 一样拿到 MCPP_DEP_<NAME>_DIR;指令落通道收敛为 root/dep 共享的单一 fold(防"同一决策两处推导")。顺修:root build.mcpp 变更此前被整库 fast-path 吞掉不触发重跑。
• mcpp xpkg parse --all-os:按 xpm 声明的平台集逐 OS 校验 per-OS 段(构建路径只 splice 宿主段,windows 段的 typo 在 linux CI 上原本不可见);mcpp-index CI 可单 runner lint 多平台描述符。

备注

• e2e 新增 141–145(-idirafter 语义/增量跳写/source= /include-dir/root dep-dirs);linux 全量 e2e 134 过(3 项为既知环境性失败)。macOS/windows 断面由平台 CI 与 mcpp-index spike 复现件(PR#89/90/91)收口。

v0.0.99

#230–#243 批次收尾:#243 feature 转发落地(0.0.98 只出了设计)+ #238 根因修复随 xlings 0.4.67 vendored 入包 + #230 windows build.mcpp 次生面补齐。设计见 .agents/docs/2026-07-19-v0.0.99-feature-forwarding-238-230-design.md。

新增

• feature 依赖 feature 转发 dep/feat(#243,Cargo 平价):[features] 里含 / 的 token(或表格形专用 forward = ["dep/feat"] 键)表示"本包该 feature 激活时,顺带打开依赖 dep 的 feat feature"——一个 feature 既能本地拉源、又能开依赖的重档 feature,解阻塞模块包的可选模块接口(opencv-m 的 import opencv.dnn;:dnn 一档同时拉 dnn.cppm 源集并把 compat.opencv 以 features=["dnn"] 参与构建,而非对所有消费者全量 +309 TU)。收敛为一数据模型 featureForwards 两文法(TOML 与 xpkg 描述符共享唯一切分点 split_feature_forward_token);转发注入 0.0.98 既有的 aggregatedRequest 依赖边漏斗(在子依赖 push 进 worklist 前把转发 feature 并入其请求集),一处注入同时覆盖解析(mergeActiveFeatureDeps 拉被转发 feature 的条件依赖)与激活(边图 union → apply() 发宏/源集)两个消费点;沿 BFS 前向边天然传递(root→mid→leaf)。与 #242 default-features = false 加性组合(转发进显式请求集、不受默认门控影响),mcpp build/mcpp test 双路径一致。转发到未声明依赖 strict 报错 / 非 strict 告警;转发未声明的依赖 feature 复用既有 "does not declare requested feature" 门。单测 3 例、e2e 128(含双路径)。

修复

• ≥2 项目级 index_repo 时 install_packages 静默失败(#238,根因修复上游落地):vendored xlings 由 0.4.62 升至 0.4.67,携 openxlings/xlings#374 的多仓安装修复(fix(xim): surface multi-repo install failures + best-effort catalog,commit cf9b60d5)。此前 workspace 根级 [indices] 继承(#224)× default 重定向(R6)组合会给每个成员播下 ≥2 个 index_repos,任一未缓存包安装裸 exit 1 无 error 事件;0.0.98 已在 mcpp 侧把它变成可操作诊断,0.0.99 随 bundle 带上真正的解析修复。发布/交叉构建/e2e 三处 workflow pin 同步 0.4.67。
• windows 下依赖/成员 build.mcpp 产物名缺 .exe 无法执行(#230 次生面):build.mcpp 编出的宿主程序此前恒名 build.mcpp.bin;windows 的 capture_exec 走 cmd.exe,.bin 不在 PATHEXT 故无法按名启动 PE。现按平台取后缀(windows=build.mcpp.exe,其余保持 .bin,is_windows 为 constexpr,非 windows 字节不变)。此面在 0.0.96 的 scanner symlink-逃逸崩溃(df985df,裸 127 的真凶)修复后才会被 workspace 的 build-mcpp 成员在 windows 走到。

备注

• #230 主因(scanner glob 顺 .mcpp/.xlings symlink 逃逸进 vendored 索引、CJK 文件名触发 MSVC 窄串转换抛异常→__fastfail→裸 127)已于 0.0.96 根治并在 0.0.98/0.0.99 在库;src/main.cpp 顶层 catch 兜底(未捕获异常→exit 70,不再裸 127)。0.0.99 补齐 build.mcpp 次生面后,mcpp-index 的 workspace(windows)CI 从临时钉回的 0.0.94 升到 0.0.99 复验全绿即关闭。

v0.0.98

#230–#243 批次(单 PR 统一发布,逐 commit):#233 对象路径消歧的两个后续缺口(#239/#240,解阻塞 mcpplibs #79 opencv 收录)+ #237/#241/#242 根因级实现 + #238 mcpp 侧诊断(根因在 openxlings/xlings#374)+ #243 设计。总账 + 架构评估见 .agents/docs/2026-07-19-issues-230-243-batch-ledger-and-architecture-assessment.md;各设计文档见 .agents/docs/2026-07-19-*。

新增

• MCPP_DEP_<NAME>_DIR build.mcpp 契约(#241):包的 build.mcpp 现可经 mcpp::dep_dir("<name>") 拿到依赖的安装目录(verdir/payload 根),不必再逆向 store 布局(实例:compat.opencv 的 unifont feature 读数据资产包 compat.opencv-unifont 的字体 blob)。用权威的 consumer→dep 边图注入,覆盖 feature 激活的依赖;canonical + short 双发(dep_dir("compat.zlib")/dep_dir("zlib") 皆可)、同款 sanitize、碰撞守卫、自动进 rerun hash。作用域为依赖侧 build.mcpp(root 工程 build.mcpp 早于依赖解析运行,列为后续项)。
• 消费端 default-features = false(#242):依赖 spec 支持关闭该依赖的默认 feature 集({ default-features = false, features = ["x"] }),Cargo 平价。根因收敛在 feature_closure 的单一 seedDefault 门:关闭时不 seed 该依赖 [features].default,仅显式请求 + implies 激活;root 包/工程 build.mcpp 仍默认 seed。(挡住 compat.ffmpeg 裁剪档形态。)

修复

• 消歧后链接输入未跟随改名,依赖与消费者同名源即挂(#240):当依赖包与消费者存在同名源(近乎必现——双方都有 src/main.cpp,如 OpenCV 自带的 sample main.cpp × 消费者的入口)时,#233 已把被扫描的消费者 main 编到 obj/<pkg>/src/main.o,但链接步骤仍引用消歧前的扁平 obj/main.o → ninja: error: 'obj/main.o' … missing and no known rule。现将对象路径分配收敛为单一来源:被 glob 进来的入口复用其编译边已消歧的对象;未被 glob 的入口也纳入同一碰撞普查后消歧——链接输入与编译边永不背离。常见单二进制工程(main 唯一)仍为扁平 obj/main.o,字节不变。
• 绝对/越根路径源的消歧对象逃逸出 obj/(#239):依赖 build.mcpp 写进 OUT_DIR(target/.build-mcpp/deps/<name>@<ver>/out/,在包根之外)的生成源,其 relPath 携带 ..,#233 曾原样拼进 obj/<pkg>/../… 致对象路径爬出构建树(甚至在 CWD 镜像整棵绝对路径树);且路径里的 @ 会被 ninja 单引号包裹,连带压垮 #235 的 "$out.d" depfile 重定向。现消歧前缀逐分量净化:去绝对根、. 丢弃、..→__up、非可移植字符(如 @)→_——对象永远向下且 shell 安全;逐分量单射,保住 #233 的唯一性(L1b 断言兜底残余)。
• xpkg 描述符 mcpp 段未知键 build 时静默忽略(#237):dependencies 误写(正确键 deps)等未知键此前只有 mcpp xpkg parse 报,build 路径静默丢弃致依赖消失无诊断。现描述符被采纳为依赖时按键响亮告警并给 did-you-mean(封闭词表别名 + Levenshtein 回退);沿用 0.0.97 封闭文法先例,告警而非硬错以保前向兼容。
• feature 请求集收敛到依赖边图(#242 传递边 + #241 命名;架构评估头号优化):此前 feature 请求集在解析(mergeActiveFeatureDeps,读 per-edge spec)与激活(apply(),只扫 root 直接依赖)两处独立推导且对传递边不自洽——传递依赖的请求 feature 与其消费者的 default-features = false 被静默丢弃(激活仍 seed 该依赖默认 feature,定义其宏/保留默认门控源,而解析已跳过)。现 DependencyEdge 携带 per-edge requestedFeatures + defaultFeatures,新 aggregatedRequest 对某依赖包所有入边做 union/OR(Cargo 菱形语义),激活与依赖 build.mcpp 共享之;直接依赖行为不变,顺带补掉长期的传递 feature 未传播缺口。e2e 127。
• 多 index repo 下 install_packages 失败无诊断(#238,根因在 xlings):裸 fetch failed (exit 1) 现重建为可操作诊断——点名目标、已配置 index repos 清单、≥2 仓的已知 xlings 解析缺口提示、保留子进程输出、MCPP_VERBOSE=1 看原始调用。仅诊断改进;多仓解析的根因修复须落在 openxlings/xlings(已开 openxlings/xlings#374)。

设计(未实现,后续 PR)

• #243 feature 依赖转发(dep/feat):核实条件依赖半边已存在([feature-deps]/xpkg features.x.deps),真正缺口是转发;设计见 .agents/docs/2026-07-19-issue-243-feature-forwarding-design.md,收敛为单一 per-package 请求 feature 漏斗(顺带补 prepare.cppm:2653 传递性缺口),与 #242 opt-out 加性组合。

备注

• #230(windows workspace exit 127)已于 0.0.96 修复,待 mcpp-index windows CI pin ≥0.0.98 复验后关闭。

v0.0.97

架构级修复批次(单 PR,逐簇 commit):ffmpeg-m/opencv-m 全源码直编暴露的第二层缺口 + workspace 测试基建语法空洞。

新增

• [[build.flags]] 数组表写法(#227):[build].flags 现同时接受 TOML 标准数组表 [[build.flags]] 与内联表数组两种等价写法(声明顺序=应用顺序不变),长 per-glob flags 条目不再挤单行。纯解析层扩展(自研 TOML parser 补全 array-of-tables);并加清单层 closed-grammar 守卫——非白名单段落误写 [[x]](如 [[dependencies]] 手滑)现硬报错而非静默丢数据。
• glob 花括号交替 {a,b}(#228):sources/flags glob 支持 libavcodec/{aac,bsf,hevc}/** 笛卡尔展开(嵌套/多组均可),vendored 大库 per-glob 声明不再重复。
• 默认命名空间索引重定向(R6):[indices] default = { path = "..." }(亦接受空引号键 "")可把默认命名空间(namespace = "" 的模块包)指向本地 checkout,补上此前只能重定向具名命名空间的语法空洞——使 index 仓能以 mcpp test --workspace 声明式验证 imgui/ffmpeg/opencv 等模块包,替代逐包 smoke shell。(url 形式的默认命名空间重定向暂不支持,解析期显式报错而非静默失效。)
• mcpp run -p <member>:run 命令支持选择 workspace 成员并运行其二进制(与 build/test 的 -p 对齐)。

修复

• 源发现全树遍历致 mcpp run 前慢 + 缓存复用(#225):glob 遍历改从字面前缀起(src/** 从 src/ 起走,不再从项目根扫全树),并排除 .git/target/git 子模块边界;mcpp run 复用 mcpp build 已解析的缓存,不再每次重扫大子模块(此前含大 compat/ 子模块时每次 ~9.5s)。
• 相对 include 族 flag 未按项目根重写 + 含空格值未转义(#226 #234):-iquote/-isystem/-idirafter/-iprefix/-L 现与 -I 一样按项目根绝对化(joined 与 separated 两拼写);defines = ["T=long long"] 等含空格值发射时 shell 引号保护,不再被拆成孤立参数。含 [build] include_dirs 在 MSVC 方言下的相对路径绝对化亦一并修正。
• 对象路径按父目录名折叠致同名源冲突(#233):不同目录同名源(a/src/util.cpp vs b/src/util.cpp,OpenCV/LLVM 式 modules/<mod>/src/* 布局)对象路径改按碰撞时镜像源相对路径消歧 + 构建后唯一性断言;非碰撞项路径字节不变。
• 模块 purview 内文本 #include 改动不触发重编(#235):编译边补 depfile 追踪(过滤 GCC -fmodules 注入的反向规则以规避 ninja inputs may not also have inputs),purview/GMF/普通头改动均正确触发重编——顺带根治此前非 MSVC 下普通头改动也不重编的潜伏问题。
• 依赖包 cfg 条件 sources 被消费时不展开(#229):path/git 依赖的 [target.'cfg(...)'.build].sources 现与 root/version-dep 同样按已解析 target 求值(mcpp build 与 mcpp test 双路径),不再 undefined reference(与 #218 同类,收敛为统一 per-package 求值)。
• nasm 冷环境惰性自举时序(#232):nasm 供给改走工具链同款同步门 Fetcher::resolve_xpkg_path("xim:nasm@3.02", autoInstall=true)(索引刷新前置 + 硬报错 + payload 校验),不再先判死后台补装;config 自举错误不再被 if(cfg) 门吞成误导性的 "no usable nasm"。
• workspace 根配置无法一次声明全员可用(#224):[workspace.dependencies] 的 path 依赖可被成员经 .workspace = true 继承;根 [indices] 的相对 path 按 workspace 根解析(而非消费成员目录),成员不再需重复声明各自 ../ 相对路径。

备注

• #230(windows workspace 崩溃)已于 0.0.96 修复。#215(cppfly Clang 反射行)待上游 Clang 落地 P2996,不排期。

v0.0.96

修复

• [windows] mcpp test --workspace 静默崩溃(裸 exit 127,实为 0xC0000409)
  (#230,修复 #231)。三层根因:
  1. 0.0.95 扫描器的 glob walk 新增 follow_directory_symlink,而项目本地
     .mcpp/.xlings/data/<index> 是指回索引根的符号链接 → walk 逃逸出成员
     目录、扫遍整个索引 checkout(CI 里含 vendored xim-pkgindex);
  2. path_matches_glob 用 generic_string() 拼窄串,MSVC 在非 CJK ANSI 代码页
     (runner ACP=1252)下遇到中文文件名 bug-report---问题反馈.md 抛
     std::system_error;
  3. 异常逃出 main 未捕获 → std::terminate → __fastfail(0xC0000409),
     git-bash 显示为无任何输出的 exit 127。
  • 修复:expand_glob/expand_dir_glob 按名剪枝 .mcpp 目录(mcpp 自身
    元数据目录永远不是源码目录,从源头切断符号链接逃逸,顺带避免每个成员把
    整个索引树白走一遍);path_matches_glob 对无法窄化的文件名按"不匹配"
    跳过而不是摧毁构建;main() 增加最后防线 catch,逃逸异常打印真实错误并
    以 70 退出,不再静默 fastfail。
  • 取证:runner 开 WER 全内存 dump,崩溃栈+被转换字符串逐帧还原(记录见
    mcpplibs/mcpp-index debug/mcpp230-windows-repro 分支及 #230)。
  • 回归测试:tests/e2e/113_scanner_mcpp_dir_prune.sh(.mcpp 符号链接逃逸
    必须被剪枝;CJK 文件名不得致命)。linux 行为对照:0.0.95 会顺着该符号链接
    把项目外源码编进来(链接期 duplicate main),修复后构建干净。

v0.0.95

(no CHANGELOG entry found for 0.0.95)

v0.0.94

修复

• 依赖包被激活 feature 的 sources 在 mcpp test 下不编译。prepare_build()
  把 feature 源集解析(drop + add)整段门在 !includeDevDeps,而 mcpp test
  走 includeDevDeps = true → 激活 feature 的 sources 从不被加回构建图。
  descriptor 若把某个 glob 只写在 features 下(xpkg 的 features.X.sources
  只落进 featureSources、从不进 base sources),该包在 mcpp build 下正常、
  在 mcpp test 下必然链接失败(undefined reference)。
  • 命中面:compat.cjson 的 utils(cJSONUtils_*)、compat.eigen 的
    eigen_blas(dgemm_)、compat.spdlog 的 compiled。
  • eigen_blas 的 dgemm_ 一直被记为「把 feature 编出的依赖目标链进 test
    二进制是 follow-up」——定性是错的:不是链接问题,是源集解析问题。
  • 修复:drop 仍只在 build 模式做(mcpp test 需要保留完整源面,让 dev-dep
    轨的 per-test main 检测看得见 gtest_main.cc 并逐 test 剪枝——见
    tests/e2e/79_gtest_regular_dep_feature_main.sh);add 改为两模式都做,
    并去重,使 gtest 那种 base/feature 双列的 glob 不会进两次。
  • 回归测试:tests/e2e/100_feature_sources_test_mode.sh(cjson utils 在
    mcpp test 下必须编译并链接;mcpp build 仍正常;不请求 feature 时 gated
    源仍被排除)。

v0.0.93

变更(命名统一,全部旧拼写永久兼容)

• 工具链 × 目标 命名统一 —— 二轴身份模型。toolchain = family@version
  (family 只剩 gcc | llvm | msvc),target = mcpp 自有三段 triple
  arch-os[-env](Zig 式砍 vendor)。变体(gnu/musl/msvc)进 triple env 段,
  "cross"/"musl"/"mingw" 不再是工具链名字——mingw-cross 16.1.0 的本体是
  gcc@16.1.0 → x86_64-windows-gnu,交叉只是 host≠target 的关系。业界对照
  (rustup 零 "cross" 命名/Zig 三段 triple/musl.cc 分发层先例)与决策记录见
  .agents/docs/2026-07-15-toolchain-target-naming-unification-design.md。
  • canonical triple:x86_64-windows-gnu 为正典(D1);GNU 拼写
    x86_64-w64-mingw32 及 4 段 Rust 拼写为永久别名,归一后进同一
    target/<canonical>/ 目录(同一构建缓存)。macOS 产物目录随 canonical 变为
    aarch64-macos。
  • --target 封闭词汇表校验:打错字硬错 + did-you-mean
    (did you mean 'x86_64-linux-musl'?),不再静默 fall through 编成宿主产物
    (最坏失败模式根治);自定义 triple 走显式 [target.X] 节逃生舱;planned
    档位(riscv64 等)报「registered but not yet supported」。两条硬编码约定
    (*-musl、x86_64-w64-mingw32)改为词汇表数据行(pin + 默认 static)。
  • 单一 triple 解析器 triple.cppm:cfgpred/abi/model 谓词/registry 四处
    平行解析收敛;abi 的 os 维 darwin→macos(与 cfg 词汇分叉消灭,
    darwin/arm64 作为约束别名接受)。
  • compat.cppm 兼容层:唯一知道旧拼写的文件(musl-gcc/gcc@V-musl/
    -gcc/mingw/mingw-cross/clang),归一 + 单行 note: 提示;xim 分发包名
    (mingw-cross-gcc 等)不动——"cross" 在分发层合法(musl.cc/Debian 先例)。
  • CLI 单名词 + --target 选项(D4,不设 mcpp target 子命令):
    toolchain install [gcc 16] --target <triple>(family 可省→约定 pin)、
    toolchain default gcc@16 --target <triple>(默认变 pair,持久化
    default + default_target 两键)、toolchain remove … --target <triple>;
    主路径仍是 mcpp build --target <triple> 自动装链(零仪式)。
  • [build] target = "<triple>" 新 manifest 键(≙ cargo build.target):
    「默认全静态 musl」的正确归宿(产物属性,非编译器家族属性);优先级
    --target flag > [build] target > 全局 default_target > host。
  • toolchain list 两轴重排:Toolchains 块(family@version)+ Targets 块
    (target × 状态 installed/available/planned,planned 行使词汇表用户可见);
    修版本字典序排序 bug(9.4.0 不再排在 15.1.0 前);gcc X-musl 行不再被
    llvm 劈开。README 平台表从词汇表重画(target × tier 维度,补 MSVC=✅ 与
    windows-gnu 行——旧表 MSVC 仍标 planned 是错的)。
  • 修 Windows host 上 mingw 的门:Linux 上 toolchain install mingw 现在
    合法(= 装交叉 payload,同一身份 host 分流);mcpp run 位置参数 help 改为
    「Binary name」消除与 --target 的语义撞名。
  • 验证:单测 35(新增 triple/compat 套件);e2e 新增 103(typo/planned/逃生舱/
    [build] target/别名同目录)、102 双拼写断言;本机实测双拼写同 Resolved
    行+同缓存(alias 二跑 0.07s 全命中)、PE wine 真跑、musl 静态链、typo
    did-you-mean。