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 environment override.
  • 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.

Emacs 29.3 (Org mode 9.6.15)