Repository navigation
[bug] 模块 purview 内文本 #include 改动不触发重编(stale build;gen_exports/*.inc 模式) #235
Description
现象
模块 purview 内的文本 #include(如生成的导出清单 .inc)被修改后,mcpp build 判定 up-to-date(0.01s),产物 stale —— 依赖扫描没有把 purview 文本包含计入模块 TU 的输入。
最小复现(mcpp 0.0.95,linux-x86_64)
repro/
├── mcpp.toml # kind="bin", main="src/main.cpp"
├── src/vals.inc # export inline int answer() { return 41; }
├── src/m.cppm # export module m;
│ # #include "vals.inc"
└── src/main.cpp # import m; printf("%d", answer());
$ mcpp run
41
$ sed -i 's/41/42/' src/vals.inc
$ mcpp run
41 # ← stale;期望 42(且构建输出 Finished in 0.01s,未重编 m.cppm)真实场景
ffmpeg-m / opencv-m 的模块层把生成的 export using 清单放在
src/gen_exports/<mod>.inc,由模块接口文件在 purview 内 #include
(ffmpeg-m 978 函数、opencv-m ~2000 名字的导出面都走这个模式)。重新生成
清单后 mcpp build 不重编,拿到旧导出面 —— 开发期极易踩(需手动 touch
.cppm 或清 target)。
GMF(module; 段)里的 #include 是否同样漏跟踪未单独验证;修复时建议
两处一并覆盖(gcc 的 -MD 依赖输出/.ddi 应该都已含这些路径,疑似是
扫描结果没被并入 ninja 依赖边)。
期望
模块 TU 的任何文本包含(GMF 与 purview)都参与 up-to-date 判定。
Activity
fix(build): scope #235 compile-edge depfile to GCC; e2e 118 requires gcc
feat: 0.0.97 架构级修复批次 (#224-#235 + R6) (#236)
Sunrisepeak commentedon Jul 18, 2026
✅ 已在 mcpp 0.0.97 修复(GCC;PR #236,
3b4f18e/78bb1c9,簇 C)。模块 purview / GMF 内文本
#include(以及普通头)改动现正确触发重编:cxx_module/cxx_object编译边加 gcc depfile 追踪(过滤 GCC-fmodules注入的反向规则以规避 ninjainputs may not also have inputs)。顺带根治了此前非 MSVC 下普通头改动也不重编的潜伏问题。范围说明:当前实现为 GCC 专用(awk 过滤针对 GCC
-fmodules反向规则;Clang.pcm模块 depfile 形态不同,保持 pre-#235 行为=与 0.0.96 一致,非回归)。Clang/MSVC 的 purview 重编追踪作为后续跟进(e2e118_purview_include_rebuild.sh已# requires: gcc)。若需要我可单独开一个 Clang 跟进 issue。验证:e2e
118_purview_include_rebuild.sh(改.inc后重编取新值,红→绿)。test(e2e): repros for object-path #240 (same-named main) + #239 (out-…
fix(build): unify object-path assignment so entry-main follows disamb…