Repository navigation
Windows: installing a payload during mcpp build leaves the registry's shim directory at the front of PATH for every action, so llvm's cl/link/lib shims shadow MSVC #726
Description
Observation
GalTranslPP on windows-2025 (Sunrisepeak/GalTranslPP#3), mcpp 2026.9.27.1, llvm@22.1.8 with msvc@system, mcpp:plugins 0.16.0 deps-vcpkg. On a build that installs the toolchain or a payload itself, the vcpkg install action fails:
Detecting compiler hash for triplet x64-windows...
error: while detecting compiler information:
The log file content at "...\bt\detect_compiler\stdout-x64-windows.log" is:
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
The same vcpkg install command run outside mcpp succeeds. A second mcpp build, or a build after mcpp emit build-database installed the payloads in another process, succeeds.
Cause
On Windows, build_command_prefix (src/xlings/xlings.cppm) sets XLINGS_HOME and prepends the registry's shim directory to the process PATH:
mcpp::platform::env::set("XLINGS_HOME", env.home.string());
mcpp::platform::windows::prepend_path(xvmBin);ScopedInvocationEnv restores only the scope variables. As its comment states, "XLINGS_HOME and the PATH prefix keep their process-wide lifetime". Each xlings invocation during provisioning therefore prepends <mcpp home>/registry/subos/default/bin once more; three copies were observed. ninja and every action started afterwards inherit this PATH.
That directory holds the shims xim:llvm registers on Windows:
clfor clang-cl;linkfor lld-link;libfor llvm-lib;rcfor llvm-rc.
vcpkg runs vcvarsall to detect MSVC for the host triplet, and that detection then meets these shims instead of MSVC's tools.
On POSIX the same values are part of the xlings command prefix and never reach the build.
Evidence
-
Environment of a build action. It was compared with the job's environment by an action running
cmd /c set(run 36321504631). The action'sPATHgains<mcpp home>\registry\data\xpkgs\xim-x-llvm\22.1.8\lib;<mcpp home>\registry\subos\default\bin(the second directory three times). The action also getsXLINGS_HOME=<mcpp home>\registry. -
Isolation. A direct
vcpkg installwas run under each environment, 60 s each (run 36322488531):Environment Result The job's environment Passes compiler detection The registry's shim directory in front of PATHFails with the message above The XLINGS_*variables alonePasses The project's own SubOS binin front ofPATHPasses -
mcpp started directly. When provisioning is not part of the same process, compiler detection passes and the installation proceeds (run 36321827736).
Expected
The registry's shim directory and XLINGS_HOME reach the xlings child process only, as on POSIX. They should not reach the build.
Suggested direction
- Have
ScopedInvocationEnvsave and restorePATHandXLINGS_HOMEon Windows as well, so thatbuild_command_prefixno longer changes the process. - Alternatively, give the xlings child its environment directly.
Activity
speak-agent commentedon Sep 27, 2026
A second difference from the POSIX prefix surfaced in the next run (Sunrisepeak/GalTranslPP run 36323236500). In that run the payloads were installed by a separate
mcpp emit build-database, so the build process itself never called xlings:The POSIX prefix runs xlings from its home; the Windows command runs it from mcpp's working directory. The two lines are:
cd <home> && env ... xlingsxlings chooses project mode from that directory. It walks up from its working directory to a
.xlings.json(src/core/config.cpp) and exportsXLINGS_PROJECT_DIR.GalTranslPP pins its mcpp in such a file at the root. So the registry's xlings adopted the project and wrote the shims of mcpp's toolchain and payloads into the project's SubOS,
.xlings\subos\_\bin:cl,link,lib;clang;cmake;7z;llvm-*tools.That directory is on
PATHin any shell inside the project, and the shims there resolve against the user's home. In that home the payloads are not installed, which produces the error above.The fix in #727 covers both differences:
ScopedInvocationEnvapplies and restoresPATHandXLINGS_HOME, not only the scope variables;cd /d "<home>" &&, as the POSIX one starts withcd.docs: #726 and #727 join the round (W13); the split moves to the last…
2026.9.28.1: eight reports (#717, #718, #720, #722-#726), one downloa…
build: mcpp 2026.9.28.1, the release in which an xlings invocation on…
speak-agent commentedon Sep 27, 2026
Implemented in 2026.9.28.1 (#727). On Windows an xlings invocation made by mcpp now affects only the xlings child process, as on POSIX.
ScopedInvocationEnvappliesXLINGS_HOME, the scope variables and thePATHprefix of the registry'ssubos/default/binfor the duration of one invocation, and restores them afterwards, newest first.cd /d "<home>" &&, so xlings no longer walks up from the project to a.xlings.jsonand adopts the project.Real-world reading. GalTranslPP (Sunrisepeak/GalTranslPP#3) builds a workspace with vcpkg and Qt, and has a
.xlings.jsonat its root.vcpkg was unable to detect the active compiler's informationmcpp build --workspace,mcpp run -p GPPCLI,mcpp pack --format release, the CLI starting from the release layout,emit build-databaseThe only change between the two runs is the mcpp pin in
.xlings.json(commit bf8ffc4f).In the suite,
tests/unit/test_xlings.cppasserts that neitherPATHnorXLINGS_HOMEoutlives an invocation, and asserts the exact Windows prefix for a home whose path contains a space. PR #727's Windows CI rows pass.