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。

v0.0.92

新增

• Linux → Windows MinGW-w64 交叉工具链(mingw-cross)—— host≠target 一等公民。
  在 Linux 主机上交叉编译出 Windows x86_64 PE,含 import std。补 0.0.89
  msvc-mingw-design §4.4/§7 登记的延期项(交叉维:host≠target)。
  • 工具链:从源码构建的 GCC 16.1.0 mingw-w64 MSVCRT 交叉链(triple
    x86_64-w64-mingw32,跟随 Rust Tier-1 x86_64-pc-windows-gnu 的 CRT 选型);
    自包含(自带 binutils/CRT/libstdc++ 含 bits/std.cc + libstdc++exp);
    发布于 xlings-res/mingw-cross-gcc(GitHub+GitCode)+ xim-pkgindex。
  • mcpp 侧:用户名 mingw-cross → xim mingw-cross-gcc(前端
    x86_64-w64-mingw32-g++);解除 MinGW 的 Windows-host 门(Linux 主机可装,native
    mingw 仍 Windows-only);--target x86_64-w64-mingw32 约定解析(默认 static);
    跳过 glibc/linux-headers(PE 自带 CRT)。
  • host≠target 化:PE 产物形态判断一律按 target 而非 host constexpr——std 模块源
    探测补 <prefix>/<triple>/include/c++/ 子目录;自包含工具链跳过外部 binutils -B
    (musl + mingw);MinGW link 分支(-static / -lstdc++exp)由 if constexpr(is_windows)
    host 门提为运行期 is_mingw_target target 判定。
  • 验证:e2e 102_mingw_cross_wine.sh(# requires: mingw-cross wine,build --target
    → PE 静态自包含断言 → wine 跑 import std + 多模块);CI cross-build-test.yml 加
    mingw-cross-wine job(OS-cross,wine)。全链实测闭环(install→build→wine)。
  • 设计:.agents/docs/2026-07-15-mingw-linux-cross-windows-design.md。

v0.0.91

新增

• standard = "c++fly" — 一行启用"最新标准 + 全部实验特性"(语言 + 标准库)。
  语义三件套,全部按 resolved 工具链自动判定:①族最新 -std= 档位(GCC16→c++26、
  Clang→c++2c、MSVC→/std:c++latest);②该工具链支持的全部实验性语言特性门
  (GCC≥16:反射 -freflection;契约随 -std=c++26 默认启用,实机探测定案);
  ③标准库实验门(libc++→-fexperimental-library)。不支持的特性软跳过并打印
  summary(c++fly on <toolchain>: <std>; enabled: ...; skipped: ...)。
  新模块 src/toolchain/cppfly.cppm 承载三张数据表(族×版本×stdlib)——首个真正
  使用 Toolchain::version 做门控的查询点;产物汇入 0.0.90 的图全局方言旗标通道
  (全图 TU + P1689 扫描 + std BMI 预构建同源),派生旗标并入指纹。
  设计:.agents/docs/2026-07-14-std-features-experimental-gate-design.md。
  e2e 100(gcc16 硬路径:零手写旗标跑通 std::meta 反射)/ 101(clang 软路径:
  c++2c + skipped summary)。

修复

• standard = "c++latest" 在 GNU 族误拼 -std=c++latest(GCC/Clang 不识别,
  构建必败):canonical 现经 cppfly 的"族最新档"表解析为真实档位(GCC16→
  -std=c++26)。e2e 100 尾段回归覆盖。

v0.0.90

新增

• MSVC 原生构建后端(cl.exe)落地,0.0.88 的构建门移除。选定 msvc@system
  后 mcpp build/run 直接用系统 MSVC 编译链接:
  • 环境模型:find_windows_sdk() + 从检测到的 VC tools/SDK 直接合成
    INCLUDE/LIB/PATH(+VSLANG=1033),不跑 vcvarsall;SDK 缺失时检测/选择仍可用,
    构建报带指引的明确错误;doctor 新增 SDK 与 mingw 检查行。
  • 模块管线:std/std.compat.ixx 单命令 staging(/ifcOutput → ifc.cache),
    命名模块 .cppm 经 /interface /TP 编译、/ifcSearchDir 消费;
    /scanDependencies 作为第三个编译器内建 P1689 扫描驱动接入 dyndep。
  • 链接:link.exe/lib.exe(SeparateLinker)+ 响应文件(绕 cmd 8191 限制),
    DLL=/DLL /IMPLIB:;deps=msvc(/showIncludes)头文件依赖;/MD|/MT CRT
    随 linkage;/std:c++20|c++latest 映射;.obj 扩展名全链路。
  • fast-path 增量:构建缓存 env 槽新增 @env 多变量编码,增量构建重建
    INCLUDE/LIB 环境。e2e 99(模块/import std/增量)+ 95 改造为真实构建断言。
• [build] dialect_cxxflags + 方言旗标全图化(issue #210 修复)。
  -freflection 等"改变标准库头声明集"的 flag 现随 -std= 的通道到达:
  全局 cxxflags(项目+依赖所有 TU)、std/std.compat BMI 预构建命令、P1689 扫描。
  known-list 自动提升(reflection/contracts/char8_t/_GLIBCXX_USE_CXX11_ABI)+
  显式 dialect_cxxflags 逃生舱;指纹早已包含这些 flag,修的是命令构造。
  实证:#210 的最小复现(gcc16 + import std; + std::meta)输出 x 2/y 3;
  e2e 98 含依赖模块变体。

修复与优化

• mingw 在非 Windows 主机的 toolchain install/default 现在明确报
  windows-only(此前是 invalid xpkg target 'xim:mingw-gcc@')。
• std 模块 staging 命令在 Windows 用 cd /d(跨盘;工作区 D: + 缓存 C: 的
  真实 CI 布局)。
• release 的 publish-ecosystem:镜像脚本改为批量上传+带耐心的 ranged-GET 验证、
  验证超时不再删除资产(0.0.89 因逐资产"18s 即删重传"+全量 GET 探测触顶
  20min 被杀);timeout 兜底 20→30。
• stdmod 执行层支持工具链声明环境(capture_with_env);shell 引用平台化。

v0.0.89

新增

• MinGW-w64 工具链入 xlings 生态(Windows 原生 GCC,无需 Visual Studio)。
  mcpp toolchain install mingw 16.1.0 / default mingw@16.1.0:xim 包
  mingw-gcc(winlibs GCC 16.1.0 + MinGW-w64 14.0.0 UCRT 独立构建,镜像于
  xlings-res/mingw-gcc,GitHub+GitCode 双端)。复用既有 GCC 后端
  (gcm 模块管线、libstdc++ bits/std.cc 的 import std);Windows 上
  libstdc++/libgcc 默认静态链接(产物免带 DLL,[build] static_stdlib=false
  可关),linkage="static" 升级全静态。e2e 97 覆盖 install→default→
  多模块 build/run→独立 exe 验证;ci-windows 新增专项步骤。
  连带修复:toolchain list 的 Available 段与部分版本解析此前硬编码按
  "linux" 平台读取 xpkg 版本(Windows/macOS 上恒空);toolchain install
  在 Windows/macOS 不再错误安装 glibc/linux-headers 依赖。

重构

• 工具链后端抽象层(Part A,对 GCC/Clang 零行为变化,build.ninja 零 diff
  实证)。新增 mcpp.toolchain.dialect(命令行拼写 traits:gnu/msvc 两行
  数据,-I/-D/-std=/-c/-o/-O/-g/ar 及归档命令模板经其发射);BmiTraits
  并入模块旗标拼写(compileModulesFlag/stdBmiUsePrefix/
  moduleOutputPrefix/bmiSearchPrefix),flags.cppm 的 is_clang 分支改由
  数据驱动;ProviderCapabilities.has_builtin_p1689_scan 取代 ninja 后端的
  is_gcc 门;Toolchain::envOverrides(EnvVar 表,注入 ninja 子进程环境,
  为 MSVC 后端 INCLUDE/LIB/PATH 预留);gcc provider 增加与 clang 同形的
  std_module_build_commands(命令序列);resolve_link_model 在 Windows
  显式返回 PE 空模型。设计:.agents/docs/2026-07-13-toolchain-backend- abstraction-msvc-mingw-design.md + 同日触点审计文档。

v0.0.88

新增

• MSVC 系统工具链支持(msvc@system,detection-first)。MSVC 作为首个
  "系统工具链"接入:mcpp 负责定位与识别(vswhere → VSINSTALLDIR/
  VS*COMNTOOLS → 标准安装路径三级发现;cl.exe banner 解析出编译器版本/架构,
  容错本地化 banner),从不安装/卸载 MSVC 本体。
  • mcpp toolchain default msvc:检测系统 MSVC,打印 VS 产品/VC tools/
    cl 版本与 std.ixx(import std)可用性,持久化稳定 spec msvc@system
    (不落具体版本,VS 升级后配置依然有效);未安装时输出安装指引
    (VS Installer C++ 工作负载 / winget install …BuildTools)并退出非零。
    msvc@19.44 形式为 pin 校验(仍取最新 VC tools,前缀不符则报错)。
  • mcpp toolchain list:Windows 上新增 System: 段展示检测到的 MSVC;
    install msvc 报告已装现状或给指引;remove msvc 明确拒绝(系统组件)。
  • mcpp self doctor:Windows 上新增 "msvc (system)" 检查段。
  • manifest 支持 [toolchain] windows = "msvc@system"(types.cppm 注释中的
    既有 schema 首次落地);非 Windows 主机使用 msvc spec 时给出明确报错。
  • mcpp build:原生 cl.exe 构建(.ifc 管线)本版暂不支持,在工具链解析
    后以单一 owned 错误信息拦截,并提示可用的 llvm@20.1.7(MSVC-ABI Clang)。
  • detect() 新增 cl.exe 分类路径(文件名短路,banner → 版本/triple),
    bmi_traits 预置 MSVC .ifc 分支;e2e 95/96 + 单测覆盖。
  • 设计文档:.agents/docs/2026-07-13-msvc-system-toolchain-detection-design.md。

v0.0.87

修复

• 项目本地模式:不再把官方全局索引 xim 注入项目作用域。此前带自定义
  [indices](本地 path 索引)的工程进入项目本地模式时,ensure_project_index_dir
  会无条件把官方 xim 索引 append 进项目 .xlings.json 的 index_repos
  (config.cppm),意在让 xim:* 依赖在项目模式可解析。但 xlings 按"repo 落在
  哪一组"决定作用域——项目 index_repos 里的包一律 PackageScope::Project,于是
  xim 的全局工具(cmake/glibc/gcc/make/binutils 等)整体被错误地"项目化"、
  装进项目 store 而非共享 registry。由此 build-dep 工具(如 xim:cmake)的 ELF
  interpreter 被指向项目 store 里未物化的 glibc → cannot execute,任何在
  install() 里执行 glibc-动态 build-dep 工具的 compat 包(如从源码 CMake 构建的
  OpenCV)在 mcpp test 下必现,且与宿主历史无关(fresh MCPP_HOME 亦复现)。
  修复:移除该注入及配套的项目 data dir xim 副本暴露。xim(及其动态发现的
  sub-index)是 xlings 全局默认索引,global 即默认作用域——xim:* 经全局
  index_repos + registry 本地 clone 正常解析、装 registry,并经 additive 对项目
  可见;只有用户在 [indices] 声明的本地自定义索引才项目化。设计与分析见
  .agents/docs/2026-07-09-project-index-scope-global-infra-fix.md。

v0.0.86

(no CHANGELOG entry found for 0.0.86)

v0.0.85

(no CHANGELOG entry found for 0.0.85)