feat: add sccache support to CMake build backend - #5590
Conversation
wolfv
changed the title
|
Please resolve conflicts. |
FYI, I did some experiments on using sccache and The main reason for this (that is also not immediate to debug) is that fyi @EdoardoGruppi |
|
I think with the setup as proposed here we could relatively easily extend support for |
Sure, great. I wanted to write down my experience with pixi+sccache somewhere in public, so that search engines and LLM could find it. :D |
…onfig Introduce an explicit `compiler-cache` configuration option instead of auto-detecting sccache from `SCCACHE_*` environment variables. - Add `CompilerCache` enum + `build.compiler-cache` to pixi config, with `config get/set` support. - Thread the default compiler cache through the command dispatcher's compute-engine architecture via a new `CompilerCacheKey`, merging it into each backend's configuration JSON unless the package already sets it. - Add config-gated sccache support to the CMake backend (compiler launchers, build dependency, secret handling, `--show-stats`). - Migrate the Rust backend off `SCCACHE_*` env-var auto-detection to the same `compiler-cache` config option. - Document the option and update backend docs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ef92297 to
923a62c
Compare
The doc comment on with_compiler_cache linked to the private CompilerCacheKey type, which fails rustdoc::private_intra_doc_links under -D warnings. Use plain inline code instead. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
I think we need to always add sccache to the build dependencies otherwise the lockfile is unsatisfiable based on environment variables. Should also do this for rust! |
|
You mean based on the config value, right? |
|
Ah, I misread! (The description has not been updated yet). But yeah, if we now have two users, one has the compiler-cache set in their user config, they will get an unsatisfiability error because sccache is added as a build dependency, whereas the other user doesnt have that. |
A compiler cache configured globally (in the user's pixi config) is a
per-machine preference, so adding its tool to a source package's build
requirements made the lockfile flip-flop depending on whether the
machine running the resolve had the cache configured.
Distinguish the two origins via a single `compiler-cache` key whose
value shape carries provenance: a bare string (`"sccache"`) is what a
package writes in its manifest and is locked as a build dependency,
while the command dispatcher injects the tagged `{ "default": "sccache" }`
form for a global default. The global default is used as a compiler
launcher only and never locked; the tool must already be on PATH, and
the build fails with a hint to run `pixi global install sccache` if it
is missing.
Applies to both the cmake and rust backends.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
I think we will want this soon for SciPy 😉 |
|
For sccache to be really useful in this context, we basically need mozilla/sccache#2814 to be merged and released in a sccache release. |
|
I got
Would be cool if some of that was made automatic |
I may be missing something, but if you are using |
|
Indeed, this is only setup for a single machine right now |
5 participants
I believe we had this in a PR for the (old) buidl backends repository. Apparently we only merged
sccachefor Rust. This is the same for CMake.Description
This PR adds support for sccache (a distributed compiler cache) to the CMake build backend. When sccache environment variables are detected, the build system automatically:
SCCACHE_BASEDIRSto the source directory for proper cache invalidationhttps://claude.ai/code/session_01H5aie9HxzQqm5DHaHKUPGB