Skip to content

fix: 28_target_static E2E test — use isolated home + detect GNU gcc#29

Merged
Sunrisepeak merged 3 commits into
mainfrom
fix/28-target-static-test
May 12, 2026
Merged

fix: 28_target_static E2E test — use isolated home + detect GNU gcc#29
Sunrisepeak merged 3 commits into
mainfrom
fix/28-target-static-test

Conversation

@Sunrisepeak
Copy link
Copy Markdown
Member

Summary

  • Fix 28_target_static.sh CI failure ("default GNU binary missing") that has been failing on every CI run

Root Cause

Without an explicit [toolchain] in the scaffolded project and without a global defaultToolchain, mcpp's first-run logic auto-installs [email protected] as the default. The second build (intended to exercise the default GNU path) then also produced a musl binary under target/x86_64-linux-musl/, which the find -prune excluded → "default GNU binary missing".

Fix

  • Use an isolated MCPP_HOME via _inherit_toolchain.sh (symlinks the global xpkgs/config so installed toolchains are visible)
  • Auto-detect the highest installed GNU gcc version and pin it in the project [toolchain].linux
  • Skip the GNU regression check gracefully when no GNU gcc is available

Test plan

  • CI passes (both musl static build and GNU default build regression check)

Root cause: without an explicit [toolchain] in the scaffolded project
and without a global defaultToolchain, mcpp's first-run logic
auto-installs [email protected] as the default.  The second build
(intended to exercise the default GNU path) then also produced a musl
binary under target/x86_64-linux-musl/, which the find command pruned
→ "default GNU binary missing".

Fix:
- Use an isolated MCPP_HOME via _inherit_toolchain.sh (symlinks the
  global xpkgs/config so installed toolchains are visible)
- Auto-detect the highest installed GNU gcc version and pin it in the
  project [toolchain].linux
- Skip the GNU regression check when no GNU gcc is available rather
  than failing
The P0 fast-path build cache (target/.build_cache) only checked source
file and mcpp.toml timestamps.  When `mcpp build --target x86_64-linux-musl`
was followed by a plain `mcpp build`, the fast-path reused the musl
build.ninja — producing no GNU binary.

Fix: store the user's --target value as a third line in .build_cache.
try_fast_build() now compares the cached target against the current
request and falls back to a full rebuild on mismatch.

Also fix the test: detect installed GNU gcc dynamically and pin it in
[toolchain].linux so the default build uses GNU, not musl auto-install.
@Sunrisepeak Sunrisepeak merged commit a5fbcc0 into main May 12, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant