Initial client-side implementation#2735
Conversation
No behavioral change yet — the flag is wired up in a later commit.
Nothing currently uses those methods on MultiLevelStorage, so this doesn't cause practical problems, but this is going to change so they need to be implemented.
Adds LruDiskCache::get_abs_path, a Storage::get_path default method (returns Unsupported), and a DiskCache implementation that returns the absolute path of a cached entry so callers can open it directly without reading the bytes into memory first.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2735 +/- ##
==========================================
- Coverage 74.63% 74.19% -0.45%
==========================================
Files 70 71 +1
Lines 39898 40491 +593
==========================================
+ Hits 29778 30041 +263
- Misses 10120 10450 +330 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Adds six Request/Response pairs for upcoming client-side storage operations.
IpcStorage wraps a ServerConnection and implements the Storage trait by forwarding get/put to the daemon via StorageGetRaw/StoragePutRaw RPCs. get_raw/put_raw are the primary wire operations; get/put are layered on top (parse CacheRead from bytes / serialise CacheWrite to bytes). Preprocessor cache methods forward via the existing StorageGetPreprocessorEntry / StoragePutPreprocessorEntry RPCs. Sync accessors (location, basedirs, …) return values cached at handshake time so they never block.
|
I have a feature wish while you're at it: It would be cool to auto-retry failed remote builds locally and have always-on stderr output and maybe statistics for it so that one can possibly investigate and fix the problem. Sometimes a file that a remote build requires isn't captured due to a missing sccache feature. Sometimes a builder is in a borked state for whatever reason. I've observed some intermittent problem with extracting(?) the compiler archive on builders and unfortunately I haven't managed to properly diagnose and fix it. Even if that was fixed, distributed anything can fail for lots of reasons up to and including flaky hardware - I've seen that happen several times when I worked in an office with an Icecream cluster made of the local PCs. The ideal fixes for these two+ kinds of failures are quite different, but retrying locally is a nice catch-all workaround to keep the builds succeeding and minimize wasted developer time. |
This is unrelated to what this PR does. You may want to file an issue with steps to reproduce. |
The first and last paragraph are somewhat closely related, the middle two are just motivation and the usefulness is by no means limited to these. Only if distributed sccache was absolutely perfect including with future compiler changes would the feature be not useful. I don't have steps to reproduce the specific bug from the third paragraph or I'd probably have fixed it myself. I'm also considering implementing local retry myself - it's similar enough to 1ffa8d5 which also works by essentially re-invoking the build with different arguments. In that case, it would be nice of you to keep that possible extension in mind to avoid accidental difficulties for it. |
|
@ahartmetz please open an issue (or prepare a PR) to make sure it isn't forgotten |
|
This change doesn't impact distributed compilation. |
No, but it could. That's why I called it a wish. |
4 participants
No description provided.