使用本地安装的C/C++环境

首次使用mcpp时，运行mcpp run，会默认安装llvm@20，而我本机已经安装llvm22.1.3，与MinGW16.1.0。希望可以识别本机环境，尽可能从本机已经安装的环境构建。

自定义工具链的功能, 后面看看怎么做

我不认为这是一个好的想法，这会降低构建的可复现性。从本地探测环境也经常会遇到魔改工具链，比如android ndk的自定义clang，emscripten的自定clang etc。如果需要编写复杂的toml来描述自定义工具链，那我认为更应该考虑的事情是让项目把这些工具链也加入管理。唯二的问题是公司自己的魔改工具链不便于发布与编译器的体积，但我认为前者在目前不会是问题，后者的话，release状态下的gcc与clang的体积都可以接受。

我认为支持自定义工具链可以大大扩展该软件的应用场景，可以将C++开发推广到单片机编程等领域，同时对于你提到的魔改工具链的问题，我认为可以在发布包时添加诸如此包使用了自定义工具链等标识，用于提醒用户可能存在的自定义语法，由用户决定是否继续使用该包，同时在调用包管理器时也可以优先选择使用官方编译器的包。如果担心接口不兼容的问题，可以通过源码发布。

那能不能扩展 mcpp 本身支持的工具链

mcpp 本身可以支持/维护常用的工具链。自定义工具链有两个问题考量

1.定义工具链抽象接口
2.如果让 mcpp-index 生态包和自定义工具链的兼容性怎么做

第一个比较简单, 第二个比较难

@SekaiArendelle

合并到 #276

本 issue、#177(支持 cmake/make/xmake 项目)、#276(嵌入式 Linux SDK 集成)是同一个缺口的三个面——mcpp 只有「自己下载并完全掌控」这一种资源获取模式,凡是「外部已经存在的东西」都缺少一个申报入口。三条统一归到 #276 追踪。

现状(核验基线 `main@80291ca` / v2026.8.8.4)

本机编译器发现逻辑今天不存在。 tcSpec 只有两个来源 —— manifest 的 [toolchain] 与全局 config(src/build/prepare.cppm:1304-1315);两处都空就直奔自动安装官方 pin(:1606-1611)。唯一沾边的代码是 probe 的兜底:

// src/toolchain/probe.cppm:249-254
std::string cxx;
if (auto* e = std::getenv("CXX"); e && *e) cxx = e;
else                                       cxx = "g++";

没有版本检查、没有能力检查、没有候选枚举,结果也不登记成任何可命名的身份。你描述的现象(本机有 LLVM 22.1.3 与 MinGW 16.1.0,mcpp run 照样下 llvm@20)今天原样成立。

is_system_toolchain(src/toolchain/registry.cppm:369-371)只认 MSVC,Family 是封闭 enum(:30),[toolchain] 只收 family@version 不收路径 —— 所以「本机已有一份可用编译器」在当前模型里没有一个可命名的身份。

今天能用的逃生阀(未文档化)

[toolchain]
default = "system"

src/build/prepare.cppm:1555-1558 会让 explicit_compiler 留空,转而走上面那段 probe。但请注意它的三个陷阱:

兜底是字面量 g++,不是「你机器上最新的那个 clang」。macOS 上 which g++ 是 Apple Clang;Homebrew 的 llvm 是 keg-only 且 bin 下没有 g++ 这个名字。
它从未被验证过能构建成功 —— tests/e2e/14_toolchain_fallback.sh:39-40 自己写着「we don't verify success, only that the hard-error path doesn't fire」。
mcpp toolchain default system 写不进全局 config(被 src/toolchain/compat.cppm:110-151 的 normalize_spec 闭词表拒),只能手写 mcpp.toml。

更可靠的用法是显式给路径:

CXX=/opt/homebrew/opt/llvm/bin/clang++ mcpp build
CXX=/opt/sdk/bin/aarch64-linux-gnu-g++ mcpp build   # 交叉 SDK 同理,会连带采纳 SDK 自己的 sysroot

后一条走的是 probe.cppm:330-336 的「foreign but usable sysroot beats no sysroot」→ linkmodel.cppm:405-408 进 Sysroot 模式 → hermetic.cppm:112-116 整体早退。如果厂商 SDK 的 gcc ≥ 15(带 bits/std.cc),今天就能试。

关于形状的结论

@SekaiArendelle 的反对意见成立,并且本轮核验支持它:有价值的是显式声明(可复现),而不是隐式探测(不可复现)。同时 @tz12323 提的兼容性顾虑也真实存在 —— 这正是 @Sunrisepeak 说的「第二个比较难」的那一半:外部工具链下 compat 包能不能用,应该由 abi:<name> capability 机制(docs/03-toolchains.md:346)来判,而不是放任链接期爆炸。

所以 #276 里的形状是:

P0 — 把 "system" 逃生阀从「事实存在」变成「产品特性」(文档化 + mcpp toolchain default system 放行 + 外部工具链身份进 src/toolchain/fingerprint.cppm,否则换一台机器复用 target/ 会拿到别人 ABI 的对象)
P1 — 显式外部工具链/sysroot 声明;Toolchain::sysroot → CLibMode::Sysroot 这两半机制都已在(linkmodel.cppm:29-30/81-83/106-109/405-408),缺的只是入口
P2 — pkg-config,以及 abi: capability 的 ABI 兼容判据

后续讨论请到 #276;本轮全量核验的结论见 #397。

Navigation Menu

Repository navigation

使用本地安装的C/C++环境 #144

合并到 #276

现状(核验基线 `main@80291ca` / v2026.8.8.4)

今天能用的逃生阀(未文档化)

关于形状的结论

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

使用本地安装的C/C++环境 #144

Description

Activity

Sunrisepeak commented on Jun 22, 2026

SekaiArendelle commented on Jun 23, 2026

tz12323 commented on Jun 23, 2026

yizhinailong commented on Jun 23, 2026

Sunrisepeak commented on Jun 23, 2026

speak-agent commented on Aug 8, 2026

合并到 #276

现状(核验基线 main@80291ca / v2026.8.8.4)

今天能用的逃生阀(未文档化)

关于形状的结论

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

现状(核验基线 `main@80291ca` / v2026.8.8.4)