Problem
Windows x64 is the only platform without a compiler cache. After the ccache fixes (#449, #450), Linux and macOS builds drop from ~60 min / ~150 min to ~15-20 min / ~35-45 min with warm caches. Windows x64 stays at ~60 min and is now the bottleneck for create_release (which waits on Debian + Ubuntu + Windows x64).
sccache was removed entirely in PR #433 because it produced 0% hit rate and caused C1041 PDB contention (mozilla/sccache#2320) under Ninja + /MP parallel builds.
Goal
Re-enable a working compiler cache for Windows x64 so it builds in ~15-20 min like the other platforms, removing the last bottleneck from the release pipeline.
Approach to try
The documented sccache + MSVC setup (already partially in place via PR #432) is:
-DCMAKE_POLICY_DEFAULT_CMP0141=NEW
-DCMAKE_MSVC_DEBUG_INFORMATION_FORMAT=Embedded (emits /Z7, no shared .pdb → no C1041)
This is already set in _build-core.yml. What's missing / to investigate:
- Re-add
mozilla-actions/sccache-action + SCCACHE_GHA_ENABLED and -DCMAKE_C/CXX_COMPILER_LAUNCHER=sccache for the x64 (Ninja) build only — NOT ARM64 (VS generator ignores the launcher).
- Verify the GHA cache backend initialises before the MSVC toolchain (the original 0% hit rate came from sccache starting after cl.exe was already resolved). May need to start sccache earlier in the job.
- Apply the same
CCACHE_IGNOREOPTIONS equivalent for sccache — exclude SLIC3R_DEV_TIMESTAMP from the hash (sccache: rewrite the compile command or use SCCACHE_* filtering), otherwise the timestamp busts every entry like it did for ccache.
- Confirm
/Z7 (embedded debug info) holds under parallel Ninja so C1041 stays gone.
Reference
Acceptance criteria
- Windows x64 build shows >80% sccache hit rate on a warm run
- No
C1041 errors under parallel build
- Windows x64 release build time drops to ~15-25 min
Note
OrcaSlicer and PrusaSlicer both use the VS generator (no sccache) on Windows, so there's no upstream reference — this would be ahead of both.
Problem
Windows x64 is the only platform without a compiler cache. After the ccache fixes (#449, #450), Linux and macOS builds drop from ~60 min / ~150 min to ~15-20 min / ~35-45 min with warm caches. Windows x64 stays at ~60 min and is now the bottleneck for
create_release(which waits on Debian + Ubuntu + Windows x64).sccache was removed entirely in PR #433 because it produced 0% hit rate and caused
C1041PDB contention (mozilla/sccache#2320) under Ninja + /MP parallel builds.Goal
Re-enable a working compiler cache for Windows x64 so it builds in ~15-20 min like the other platforms, removing the last bottleneck from the release pipeline.
Approach to try
The documented sccache + MSVC setup (already partially in place via PR #432) is:
-DCMAKE_POLICY_DEFAULT_CMP0141=NEW-DCMAKE_MSVC_DEBUG_INFORMATION_FORMAT=Embedded(emits /Z7, no shared .pdb → no C1041)This is already set in
_build-core.yml. What's missing / to investigate:mozilla-actions/sccache-action+SCCACHE_GHA_ENABLEDand-DCMAKE_C/CXX_COMPILER_LAUNCHER=sccachefor the x64 (Ninja) build only — NOT ARM64 (VS generator ignores the launcher).CCACHE_IGNOREOPTIONSequivalent for sccache — excludeSLIC3R_DEV_TIMESTAMPfrom the hash (sccache: rewrite the compile command or useSCCACHE_*filtering), otherwise the timestamp busts every entry like it did for ccache./Z7(embedded debug info) holds under parallel Ninja so C1041 stays gone.Reference
CCACHE_IGNOREOPTIONS=-DSLIC3R_DEV_TIMESTAMP=*)Acceptance criteria
C1041errors under parallel buildNote
OrcaSlicer and PrusaSlicer both use the VS generator (no sccache) on Windows, so there's no upstream reference — this would be ahead of both.