fix(toolchain): list '*' reflects effective project-aware toolchain#140
Merged
Conversation
`mcpp toolchain default` and `mcpp toolchain list`'s `*` marker read only the global config.toml [toolchain] default, but the build resolver (prepare.cppm) reads the project mcpp.toml [toolchain] FIRST — it shadows the global default. So in a project with a [toolchain] section, `list` could mark `*` on a different toolchain than `mcpp run` actually resolves (the reported gcc@16.1.0-vs-gcc@15.1.0-musl divergence). Compute the effective default the same way a build does (project mcpp.toml [toolchain] for the current platform, else global config), mark `*` on it, and print a note when it comes from the project so it never silently disagrees with the build. --target overrides are not folded in (they only apply with an explicit --target).
Sunrisepeak
added a commit
that referenced
this pull request
Jun 21, 2026
* fix(build): self-heal stale build.ninja on 'missing and no known rule' When a dependency package under the registry is reinstalled/moved but keeps the same version string, the build fingerprint (which does not yet cover registry dep state) is unchanged, so the cached build.ninja is reused. Ninja then aborts with 'missing and no known rule to make it' and the build hard-fails, forcing the user to run `mcpp clean` by hand. Add that signature to is_stale_ninja_failure so try_fast_build drops to a full graph regeneration (same invocation) instead of failing — the stale graph is rewritten against the current dep state and the build proceeds. (Folding registry dep state into the fingerprint to avoid the regen entirely is a larger follow-up; see .agents/docs/2026-06-22 §T-j.) * chore: bump version 0.0.57 -> 0.0.58 Release carrying the follow-up batch: scanner raw-string fix (#138), first-run progress (#139), toolchain effective-resolution (#140), doctor runtime-dep check (#141), and the build.ninja self-heal above.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A user saw
mcpp toolchain default/mcpp toolchain listreportgcc@16.1.0as the default (the
*), yetmcpp runresolved and usedgcc@15.1.0-musl.Three views of "the toolchain" disagreed.
Root cause
mcpp toolchain default <spec>writes, andmcpp toolchain list's*reads,only the global
config.toml [toolchain] default. But the build-timeresolver (
src/build/prepare.cppm) reads the projectmcpp.toml [toolchain]first — it shadows the global default entirely (and[target.*]overrides shadow it further). So inside a project that declares
[toolchain],list's*(global) and whatmcpp runresolves (project) can point atdifferent toolchains. They are genuinely different sources of truth.
Fix
Add
effective_default_toolchain(cfg)— resolves the toolchain the same way abuild in the current directory does (project
mcpp.toml [toolchain]for thecurrent platform, else global config default).
mcpp toolchain listnow marks*on the effective toolchain and prints a one-line note when it comesfrom the project, e.g.:
--targetoverrides are intentionally not folded in (they only apply with anexplicit
--target).Test
mcpp build+mcpp testgreen (22 passed).[toolchain] default = "gcc@16.1.0"),listnow stars
gcc 16.1.0with the explanatory note — matching whatmcpp buildresolves.
Part of the 5-PR follow-up batch (
.agents/docs/2026-06-22-mcpp-followups-design.md).Note: the ABI-mismatch error already suggests both
mcpp toolchain defaultand[toolchain] in mcpp.toml, so no change needed there.