Use sccache to cache Windows release builds#2274
Merged
dellaert merged 4 commits intoborglab:developfrom Oct 10, 2025
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull Request Overview
This PR implements sccache to significantly reduce Windows CI build times from ~1 hour to ~10 minutes for cached builds. It also adds cache cleanup automation and fixes vcpkg cache efficiency.
- Adds sccache compiler caching to Windows builds for faster compilation
- Implements automatic cache cleanup after PR closure to manage storage
- Introduces optional precompiled headers support for MSVC builds
Reviewed Changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
.github/workflows/build-windows.yml |
Adds sccache setup and compiler launcher configuration for Release builds |
.github/workflows/vcpkg.yml |
Integrates sccache for Windows builds and prevents duplicate cache saves |
.github/workflows/cache-cleanup.yml |
New workflow to automatically clean up PR caches when closed |
cmake/HandleGeneralOptions.cmake |
Adds MSVC precompiled headers build option |
cmake/HandlePrintConfiguration.cmake |
Adds configuration printing for precompiled headers setting |
cmake/GtsamAddPch.cmake |
Makes precompiled headers conditional on the new build option |
dellaert
approved these changes
Oct 7, 2025
Member
dellaert
left a comment
There was a problem hiding this comment.
This is amazing! I always lamented the windows build taking so long !
Member
|
Super-cool, merging now. |
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
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.
I heard you didn't have any DevOps people :) Ready to have your mind blown?
Windows CI:
https://github.com/borglab/gtsam/actions/runs/18232137161/job/51989459877
Uncached run takes ~1 hour, build takes ~50 minutes.
https://github.com/Gold856/gtsam/actions/runs/18301774268/job/52111040305
Completely cached run takes 10 minutes, build takes ~3 minutes. More time is spent installing dependencies than building code :)
Less fantastical is vcpkg:
https://github.com/borglab/gtsam/actions/runs/18228729434/job/51906606067
~1.5 hours to complete a Windows run, build takes 49 + 39 minutes.
https://github.com/Gold856/gtsam/actions/runs/18301774262/job/52111040326
Run takes ~22 minutes, build takes ~17 + ~2 minutes. Spent 14 minutes on building the Python modules (I believe these use LTO? I assume that's why it spends so long linking.)
And obviously, these are optimal runs, with 100% cache hit rates. Real usage will be much worse. For this project, I would expect build times should take 50% less time 99% of the time compared to before, given what's modified frequently. As long as you don't touch your base headers in base or geometry, I'd expect builds to take around 10-20 minutes, assuming a header in nonlinear, sfm, or slam was modified.
sccache uploaded ~680.8 MB in the GitHub Actions Cache. You should be able to comfortably have a dozen open PRs with no object files shared between them before you overflow your cache. If you want, we can probably cache one or two more builds and still have space left over for PRs (assuming complete cache misses.)
I also took the liberty to fix your vcpkg cache so a new one isn't saved if it's a 100% match. You're already using 9 GB and you not even using 95% of it! And I implemented a cache cleaner to clean up caches after PRs are closed to free up space for other PRs.
Resolves #2255.