v0.0.77

(no CHANGELOG entry found for 0.0.77)

v0.0.76

(no CHANGELOG entry found for 0.0.76)

v0.0.75

(no CHANGELOG entry found for 0.0.75)

v0.0.74

(no CHANGELOG entry found for 0.0.74)

v0.0.73

(no CHANGELOG entry found for 0.0.73)

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)