Task: Implement Hotfix: Windows Clang CI compiler-launcher wrapper
Table of Contents
This page documents a task in the Hotfix: Windows Clang CI compiler-launcher wrapper story. It captures the goal, current status, acceptance, and any notes or results.
Goal
Split the shared clang=/=gcc hidden presets so the compiler-cache
launcher (a .sh wrapper, not a valid Win32 executable) is only seeded
via environment for Unix presets, leaving windows-clang to fall
back to CMakeLists.txt's existing WIN32-aware launcher logic.
Status
| Field | Value |
|---|---|
| State | DONE |
| Parent story | Hotfix: Windows Clang CI compiler-launcher wrapper |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-07-11 |
Acceptance
- windows-clang preset no longer inherits the launcher
environmentoverride. - Linux clang/gcc presets keep the wrapper for sccache/ccache cross-worktree cache sharing.
Plan
Diagnosed via `gh run view 29135198900`: both windows-clang-debug-ninja and windows-clang-release-ninja fail during `project()` with "ninja: fatal: CreateProcess: %1 is not a valid Win32 application" — ninja tried to run `compiler_cache_wrapper.sh` directly as the compiler-detection launcher.
Root cause: CMake seeds the CMAKE_<LANG>_COMPILER_LAUNCHER cache variable from the same-named environment variable at project()-time. The hidden "clang""gcc" presets set that environment variable to the wrapper .sh path. windows-clang inherits "clang", so it inherited the wrapper too — before CMakeLists.txt's own WIN32-guarded logic (lines ~280-311, which correctly picks the sccache/ccache binary directly on Windows) ever runs. windows-msvc* presets don't inherit "clang""gcc" so they never hit this.
Fix: extracted the environment launcher override out of "clang"/"gcc" into a new hidden preset "unix-compiler-cache-wrapper", inherited only by the 8 linux-clang-/linux-gcc- presets. windows-clang and macos-clang* presets do not inherit it, so they rely solely on CMakeLists.txt's WIN32-aware logic (Windows) or vanilla clang detection (macOS, unchanged).
Notes
Verified `cmake –preset linux-clang-debug-make` still configures and finds ccache correctly after the split. Could not run the Windows build locally (no Windows/clang toolchain available in this environment); the actual CI run on the hotfix PR is the verification for the windows-clang presets.
Test Scenarios
Manual QA scenarios (scaffolded via compass add test_scenario, run
through the QA Validation Runner panel) that verify this task. Link
new ones here as they're created; the scenario doc itself links back
via its "Verifies task" field.
| Scenario | State | Notes |
|---|---|---|
PRs
| PR | Title |
|---|---|
| #1502 | [build] Fix windows-clang CI configure failure |
Review
| Comment summary | File | Decision | Notes |
|---|---|---|---|
Result
Extracted the compiler-cache launcher's environment override out of
the shared clang=/=gcc hidden presets into a new
unix-compiler-cache-wrapper hidden preset, wired only into the 8
Linux clang/gcc presets. windows-clang and macos-clang* no longer
inherit it, so windows-clang-debug-ninja=/=windows-clang-release-ninja
fall back to CMakeLists.txt's WIN32-aware launcher logic instead of
leaking the .sh wrapper into project()-time compiler detection.
Verified locally with linux-clang-debug-make: full build and test
suite green. Both PR checks (build/lint/review/site) and two automated
Claude code reviews passed with no blocking issues.