v0.0.72

(no CHANGELOG entry found for 0.0.72)

v0.0.71

新增

• Feature 系统 v2 Stage 2a — 由 feature 激活的可选依赖:声明于 [feature-deps.<name>]
  段(或 Lua 描述符中 feature 的嵌套 deps 表)的依赖为可选依赖,仅当该 feature 处于激活
  状态(根 --features 或依赖 spec 的 features=[...])时才进入解析;声明于 [dependencies] 的
  依赖始终解析。可选性由声明位置表达,无需额外的 optional=true 标志。实现上,prepare_build
  在为根包播种解析 worklist 之前、以及在每个依赖的 manifest 加载之后,将该 manifest 的活跃
  feature-deps 合并进其 dependencies 映射,后续既有的 worklist BFS 与 Stage 3 能力绑定即自动
  接管——一个 backend-openblas feature 可同时拉取 provider(compat.openblas,
  provides=["blas"])并开启消费开关(implies=["use_blas"],requires=["blas"]),图中单一
  provider 时能力自动绑定。Lua 描述符的 feature implies 亦补齐解析(此前仅 TOML 支持)。详见
  .agents/docs/2026-06-29-feature-optional-dependencies-s2-design.md。

  实现注记:上述两个 helper(activateFeatures/mergeActiveFeatureDeps)必须为 prepare_build
  内的局部 lambda,而非文件作用域函数。若作为模块接口单元中的导出(inline)函数,其 std::map
  实例化会泄入发射的 BMI,触发 GCC 16 modules 缺陷——另一导入 std 的翻译单元随即报
  fatal error: failed to load pendings for __normal_iterator。局部化可将实例化限制在实现单元内。

v0.0.70

修复

• 首次初始化在海外网络与 GitHub 托管 CI 上的冷启动失败(index missing;patchelf / ninja
  bootstrap 失败):mcpp self env 为新建的 MCPP_HOME 播种 .xlings.json 时,将 mirror 字段
  硬编码为 "CN"。xlings 的 normalize_mirror_ 仅接受 GLOBAL 与 CN 两个合法取值,故 "CN"
  被直接采用并解析至 gitcode,致使 xlings 内置的区域探测 detect_install_mirror_() 被跳过——该例程
  经 tinyhttps::probe_latency 测量 github 与 gitcode 的连接延迟,择可达且更低延迟者。在美国区域的
  runner 上,gitcode 不可达或显著较慢(实测 github 70 ms、gitcode 1060 ms),由此索引与沙箱的冷
  bootstrap 失败。本版将播种值改为 "auto":normalize_mirror_("auto") 判定为非法取值,xlings 视其
  为未设置并执行自身探测,在美国区域解析至 GLOBAL、在中国大陆解析至 CN。镜像选择的职责由此归还
  xlings(其已基于 tinyhttps 实现该机制),mcpp 不再代为决策。播种仅在 .xlings.json 不存在时发生,
  显式的 mcpp self config --mirror CN|GLOBAL 配置不会被覆盖。

新增

• MCPP_VERBOSE 环境变量:取非空且非 "0" 的值时,为每一次 mcpp 调用启用 verbose 日志,涵盖
  e2e 脚本中未携带 flag 的 $MCPP 调用,便于 CI 诊断。该变量与既有的 MCPP_LOG_LEVEL(仅控制文件
  日志级别)互补;显式 --quiet 仍具有更高优先级。该变量已在 fresh-install 等 workflow 中启用,但
  不含运行「默认静默」输出断言的 e2e 套件。
• update_index 冷启动重试:索引同步为网络 git 操作,单次瞬时故障原会直接导致冷启动失败。本版
  改为有界退避重试(至多 3 次,退避 2 s / 4 s);成功路径于首次尝试即返回,稳态无额外延迟,仅失败
  时方触发退避。

v0.0.69

新增

• Feature 系统 v2 — feature 可贡献「包自有 defines」+ capability(provides/requires)能力绑定:
  解决「compat.eigen 启用 blas 特性后,compile_commands.json 里只有 -DMCPP_FEATURE_BLAS、
  没有上游真正读的 -DEIGEN_USE_BLAS,特性形同未启用」这一类根因——旧版 feature 激活只能产出
  -DMCPP_FEATURE_<NAME> 宏 + 门控源文件,无法表达任意宏、更无法做 backend 选择。本次按
  「功能全覆盖 + 少即是多」收敛为两个原语(详见
  .agents/docs/2026-06-29-feature-capability-model-design.md):

  • Stage 1 — feature defines:[features] 条目可写成表形式
    name = { defines = ["EIGEN_USE_BLAS"], implies = [...] }(TOML 与 Lua 描述符两面均支持);
    激活时每个裸名 define 脱糖为 -D<x> 加到该包编译标志,与自动的 -DMCPP_FEATURE_<NAME>
    并存。按行业经验(vcpkg)刻意限制为「包自有命名空间宏」,feature 不注入自由
    cflags/ldflags,以保持 feature union 组合性。
  • Stage 3 — capabilities:包/特性可 provides/requires 一个抽象能力字符串(如 blas),
    解析器从依赖图中绑定唯一 provider——确定性:[capabilities] pin / --cap 指定者胜出;
    图中恰好一个 provider 自动绑定;零个或多个未指定均硬报错(绝不静默猜测)。
    这把「静默用错/缺失后端」变成配置期显式报错。link/include 仍走既有依赖机制流动。

  Stage 2(feature 触发的可选依赖自动拉取 + 全图 feature union 统一)作为下一阶段:它需要把
  特性计算提前到依赖解析之前(解析阶段重排),风险更高,且 capability/Eigen 用例并不依赖它
  (provider 以显式依赖声明)。本次先发坚实的 S1+S3,符合设计文档「各阶段独立可发」原则。

v0.0.68

(no CHANGELOG entry found for 0.0.68)

v0.0.67

修复

• 带命名空间前缀的依赖解析失败 index entry not found in local clone(自定义 ns + 非规范文件名):
  当一个包以「裸 name + 独立 namespace 字段」形态声明(如 aimol.tensorvia-cpu:
  name="tensorvia-cpu"、namespace="aimol"),并以非规范文件名落盘在共享索引里
  (pkgs/t/tensorvia-cpu.lua 而非 pkgs/a/aimol.tensorvia-cpu.lua)时,限定请求
  aimol.tensorvia-cpu 报「索引条目缺失」,而裸名 tensorvia-cpu 却能解析。根因是
  候选消歧 selectDependencyCandidate 用「规范文件名 <ns>.<short>.lua 是否存在」当身份
  判据——描述符以非规范文件名落盘时,正确的 peer-root 候选 (aimol, tensorvia-cpu) 对消歧
  器隐形,请求被钉死在错误的首选候选 (mcpplibs.aimol, …) 上并被身份门拒绝。修复:候选消歧
  改为身份优先,经由加载路径同款的身份校验读取器(read_xpkg_lua*)按描述符声明的
  (ns, name) 定位候选,文件名不再参与身份判定——选择层与加载层从此不可能对同一候选产生
  分歧。详见 .agents/docs/2026-06-26-identity-first-resolution-no-filename.md。

v0.0.66

修复

• LLVM 工具链产物运行期 libatomic.so.1: cannot open / 真用原子时链接报 undefined __atomic_*:
  16 字节及超宽 std::atomic 会降级成 __atomic_* 外部调用,这些符号位于 libatomic
  (GCC 运行时库,LLVM 无对应物),而编译器驱动不会自动链接 libatomic。mcpp 现在在
  Linux 链接行注入 -Wl,--push-state,--as-needed -latomic -Wl,--pop-state:真正用到原子的
  程序自动链上并保留依赖,未用到的程序经 --as-needed 自动丢弃、产物零额外依赖。注入是
  自守卫的——仅当工具链链接目录里存在可解析的 libatomic(动态链接 libatomic.so/.a,
  静态链接 libatomic.a)时才发出 -latomic,因此对不附带 libatomic 的工具链零回归。
  与之配套的 llvm 资源包需把 libatomic 打入 lib/<triple>/(详见
  .agents/docs/2026-06-26-llvm22-libatomic-self-containment-design.md)。

v0.0.65

修复

• mcpp add gtest + mcpp build 报 duplicate symbol: main / LNK2005(#168):
  gtest 作为常规依赖时,其 gtest_main.cc(自带 main)被链进应用,与应用自身的
  main 冲突。修复采用通用的「feature 门控源」机制:依赖描述符可声明
  [mcpp].features.<名>.sources,被某 feature 列出的源默认不编译/链接,仅在该
  feature 被请求(dep = { version="…", features=["…"] })时纳入。gtest 描述符把
  gtest_main.cc 归入 main feature → 默认只链框架,不再撞 main;需要 gtest 提供
  main 时 gtest = { version="1.15.2", features=["main"] } 显式开启。
  门控仅作用于 mcpp build;mcpp test 保持既有的 dev 依赖 main 检测(0.0.64)不变。
  详见 .agents/docs/2026-06-25-gtest-main-feature-and-add-dev-design.md。

新增

• mcpp add --dev <pkg>:把依赖写入 [dev-dependencies](测试专属,如 gtest;
  由 mcpp test 消费,不链进 mcpp build 的应用)。

测试

• 单元 SynthesizeFromXpkgLua.FeatureGatedSources(描述符 feature 门控源解析);
  e2e 79_gtest_regular_dep_feature_main.sh(#168 哨兵 + features=["main"] opt-in +
  add --dev)。

CI

• release workflow 默认 xlings 版本 0.4.58 → 0.4.60(缓存键同步更新)。

v0.0.64

修复

• mcpp test 在自带 main() 的测试 + gtest dev-dep 下 duplicate symbol: main:
  gtest 的 gtest_main.cc 自带 main(),而 mcpp 此前把依赖的全部对象内联进每个
  测试二进制,于是测试自己的 main() 与 gtest_main.o 撞符号。修复:兑现依赖
  描述符里已声明的 kind="lib"——把这类依赖编译成静态归档 lib<pkg>.a,链接在
  测试对象之后;标准归档语义只在符号未定义时拉成员,故 gtest_main.o 的 main
  只在测试不自带 main 时才被拉入。{自带/框架 main} × {用/不用 gtest} 全部组合
  皆正确,用户无感。纯模块依赖(如 mcpplibs.cmdline,无非模块对象)行为不变。
  这是通用 link-model 改进、由既有描述符 kind 驱动,无 gtest 特例,未来
  测试框架声明 kind="lib" 即自动适配。详见
  .agents/docs/2026-06-25-dependency-archive-linking-design.md。

测试

• 新增单测 NinjaBackend.ArchiveInputsLinkedAfterObjects(归档须排在对象之后)与
  跨平台 e2e 78_test_main_combinations.sh(四种 main×gtest 组合 mcpp test 全绿)。

v0.0.63

修复

• tests/ 目录无代码提示:clangd 在测试文件里对 gtest::InitGoogleTest()、
  import std / import mcpplibs.* 全无补全。根因:compile_commands.json 是当次构建
  plan 的镜像,mcpp build 的 plan 不含 tests/**/*.cpp 与 dev-deps,而它与 mcpp test
  写同一个 cdb——后写覆盖前写,日常「编辑→build」循环里测试条目几乎总被擦掉。修复:
  write_compile_commands 由「全量覆盖」改为「合并保留」——保留当前 plan 未覆盖但
  文件仍存在的旧条目(上次 mcpp test 写入的测试条目),剪除已删文件。mcpp build 自身
  零改动:不解析、不下载任何 dev-deps,build-only 用户与构建图均不受影响(offline-first)。
  跑一次 mcpp test 后,测试补全在后续所有 mcpp build 中持久生效。
  详见 .agents/docs/2026-06-25-cdb-test-coverage-design.md。

测试

• 新增单测 tests/unit/test_compile_commands.cpp(合并/剪除/去重/坏 JSON 回退)与跨平台
  e2e 77_cdb_preserves_test_entries.sh(mcpp test 后真实重建 mcpp build 仍保留测试条目)。