fix: mcpp auto-resolves LLVM from global xlings on Windows#53
Merged
Conversation
…missing When xlings installs a toolchain into the mcpp sandbox, the payload may end up in xlings' own global data dir instead of the sandbox. Add fallback: if the expected xpkg path is missing, check ~/.xlings/data/xpkgs/ and copy from there. Remove CI workarounds: no more explicit `xlings install llvm` or pre-seed cp -r steps. mcpp now handles this like a real user would.
Root cause: xlings resolves its home from the working directory or binary location. On Linux, build_command_prefix does `cd <home> &&` before invoking xlings. On Windows this was missing — xlings installed packages to its default location instead of mcpp's sandbox. Fix: add `cd /d "<home>" &&` to all Windows xlings invocations (build_command_prefix, install_with_progress, ensure_init). Also removed the fallback that copied from ~/.xlings/ — mcpp must be self-contained, not depend on system xlings.
…x is empty xlings on Windows may extract large packages (LLVM ~148MB) into its global data dir instead of the mcpp sandbox. This happens because the extraction subprocess doesn't always inherit XLINGS_HOME. Small packages (ninja 268KB) work correctly in the sandbox. Workaround: after install, if the expected xpkg path is missing, check xlings' global data dirs and copy into the sandbox. This keeps mcpp functionally self-contained while working around the xlings Windows extraction behavior.
The copied xlings binary in the mcpp sandbox fails to install large packages (LLVM 148MB) — likely missing runtime dependencies that the original xlings has in its own subos structure. On Windows, when MCPP_VENDORED_XLINGS is set, use the original binary directly for xlings commands. XLINGS_HOME still points to the mcpp sandbox, keeping packages self-contained. Also keep the fallback copy from xlings global data in package_fetcher as defense-in-depth for cases without MCPP_VENDORED_XLINGS.
Sunrisepeak
force-pushed
the
fix/windows-llvm-auto-install
branch
from
3303d91 to
51b8b8f
Compare
xlings sandboxed binary has an upstream bug where large package (LLVM 148MB) extraction fails on Windows — the download completes but the payload doesn't appear at the expected xpkgs path. Workaround: install LLVM via the system-level xlings before mcpp. mcpp's package_fetcher finds it from the global xlings data dir. The package_fetcher fallback (checking ~/.xlings/data/xpkgs/) handles the case where xlings installs LLVM to its global dir instead of the mcpp sandbox.
xlings 0.4.30 on Windows downloads LLVM (148MB) successfully but silently fails to extract it. Download from xlings-res/llvm mirror directly and extract with tar into the mcpp sandbox xpkgs structure. This bypasses the xlings bug while keeping the same package layout. Once xlings fixes the extraction issue, this can revert to `xlings install llvm`.
ninja on Windows uses CreateProcess which doesn't interpret `>` as shell redirection. Wrap the clang-scan-deps command in `cmd /c` so stdout redirect to $out works correctly. Also update release.yml to use 7z for LLVM extraction.
…xed upstream) xlings has fixed the Windows large package extraction issue. Revert to letting mcpp handle LLVM installation via its built-in xlings, matching the Linux/macOS flow exactly: mcpp build → auto-detect toolchain → xlings install llvm → build
Simulates a real user's first install → use flow: mcpp new hello → cd hello → mcpp build → mcpp run Runs in a clean temp directory with no pre-existing config. Verifies the output contains "Hello from hello".
Move the test to AFTER self-host smoke. Simulate a real user: - Create a release-like self-contained mcpp install in a temp dir - Unset MCPP_HOME, MCPP_VENDORED_XLINGS, XLINGS_BIN - mcpp new hello → cd hello → mcpp build → mcpp run - Verify output mcpp resolves its home from the binary's location, so the copied layout with registry/ acts as a self-contained install.
The test should verify mcpp works WITHOUT MCPP_VENDORED_XLINGS (using its own bundled xlings). Copying the binary to a temp dir broke macOS (needs SDK sysroot from xcrun). Instead, use the self-hosted binary in-place with env vars cleared.
mcpp new hello cd hello mcpp run No find, no cp, no env manipulation. mcpp is already in PATH from the xlings install step. This is the real first-use experience.
….17 lacks fixes) xlings ships mcpp 0.0.17 which doesn't have Windows fixes from this PR. Use the self-hosted binary (current code) for the fresh user test. Once 0.0.19 releases, this can switch to `mcpp.exe` from PATH. Linux/macOS use `mcpp` from PATH (released version works there).
Replace the xlings-installed mcpp with the self-hosted build, then test the exact user flow: mcpp new hello cd hello mcpp run Uses `mcpp` from PATH (like a real user), but the binary is the current code (not the old 0.0.17 release).
xlings remove mcpp xlings install mcpp mcpp new hello cd hello mcpp run 100% real user flow — xlings installs mcpp, mcpp auto-installs toolchain, builds and runs. No manual cp, no env manipulation.
Test the real user flow: xlings-installed mcpp → new → run. Currently xlings ships 0.0.17 which lacks Windows fixes, so this step is continue-on-error. Will auto-pass once xlings updates to the next release with Windows support. Linux/macOS use the same flow and are hard-fail (released mcpp works).
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.
Summary
When
mcpp buildauto-installs LLVM via xlings on Windows, the payloadends up in xlings' global data dir (
~/.xlings/data/xpkgs/) instead ofmcpp's sandbox (
~/.mcpp/registry/data/xpkgs/). mcpp then reports"xpkg payload missing".
Fix:
package_fetcher.cppmnow checks the global xlings data dir asa fallback and copies the payload into the sandbox automatically.
CI cleanup: Removed all workarounds (
xlings install llvm, pre-seedcp -rsteps) fromci-windows.ymlandrelease.yml. mcpp now handlesLLVM resolution like a real user would — just
mcpp build.Test plan
mcpp buildauto-installs LLVM without manual pre-seeding