## 现象 包自身 `mcpp build` 时,`[target.'cfg(...)'.build].sources`(0.0.95 #223 的 cfg 条件 sources)正常参与构建;但该包**作为依赖**(path dep 实测)被消费时,cfg 条件 sources 不被展开编译 → 链接 undefined reference。与 0.0.94 修复的「feature sources 在 mcpp test 下不编译」(#218)属同一类:条件源集解析在非 root 构建路径缺失。 ## 最小复现(mcpp 0.0.95, linux, gcc@16.1.0) `mylib/mcpp.toml`: ```toml [package] name = "mylib" version = "0.0.1" [targets.mylib] kind = "lib" [build] sources = ["src/**/*.cppm"] [target.'cfg(linux)'.build] sources = ["src/impl.cpp"] ``` `src/mylib.cppm`: `export module mylib; export extern "C++" int impl_value(); export int probe() { return impl_value(); }` `src/impl.cpp`: `int impl_value() { return 42; }` - `cd mylib && mcpp build` → OK(impl.cpp 编译) - `app` 以 `mylib = { path = "../mylib" }` 依赖并 `import mylib;` → **`undefined reference to impl_value()`**(dep 的对象里没有 impl.o) ## 影响 多平台源列表分平台声明的包(ffmpeg-m:x86 目标编 NASM `.asm`、aarch64 目标编 GAS `.S`,源列表按 `[target.'cfg(all(<os>, arch = "..."))'.build].sources` 生成)只能作为 root 项目构建,不能被消费。ffmpeg-m 当前被迫把主平台(linux-x86_64)源列表退回 `[build].sources`,macOS 目标块等本修复后启用。 ## 期望 依赖解析/构建图生成时,对每个依赖包按 resolved target 评估其 `[target.*]` 表(与 root 包同语义);顺带确认 `dev-dependencies`/`mcpp test` 路径同样覆盖(cf. #218 的教训:add 需要在所有模式做)。
Activity
Sunrisepeak commentedon Jul 18, 2026
✅ 已在 mcpp 0.0.97 修复(PR #236,
d6b3b6c,簇 D)。依赖包(path / git)的
[target.'cfg(...)'.build].sources现与 root / version-dep 同样按已解析 target 求值,mcpp build与mcpp test双路径均覆盖(与 #218 同类,收敛为统一 per-package 求值:root + version-dep + 新增的 path/git-dep 三个正确调用点)。验证:e2e
119_dep_cfg_sources.sh(path dep 的 cfg 源 build+test 双路径,红→绿)。fix: [build].defines is a BuildInputs member, and [build] stops swall…
fix: fold [build].defines into cflags/cxxflags before P1689 scan (#297)