# \[Idea\] Cargo Global Binary Cache

**URL:** <https://internals.rust-lang.org/t/idea-cargo-global-binary-cache/9002>\
**Category:** cargo\
**Created:** [December 11, 2018, 6:19pm UTC](https://internals.rust-lang.org/t/idea-cargo-global-binary-cache/9002 "2018-12-11T18:19:25Z")\
**Posts on this page:** 1\
**Showing post:** 31

<div class="post-metadata">

**Author:** ![ehuss](https://avatars.discourse-cdn.com/v4/letter/e/9de0a6/32.png) [@ehuss](https://internals.rust-lang.org/u/ehuss)\
**Post date:** [December 30, 2018, 4:28pm UTC](https://internals.rust-lang.org/t/idea-cargo-global-binary-cache/9002/31 "2018-12-30T16:28:39Z")

</div>

I don’t have too many concrete suggestions other than being cautious about the limitations of a shared cache (especially without sandboxing and environment tracking). Some ideas:

- Consider adding RUSTFLAGS to the metadata hash.
- I think it would be fine to start with an unstable experiment, but I think gc support might be a prerequisite for stabilization.
- Consider the UI for how `cargo clean` would work. How to clean my local target vs the shared one? How will `cargo clean` evolve as it undertakes more tasks (like managing the registry caches)? Should there be separate commands, or could it take subcommands, or various flags?
- Stretch goal: Figure out some way to make this work with rustdoc.

I don’t think user-level control is a prerequisite to get started. Just consider making the logic on what to share flexible. As an example, Bazel can control what’s cached [per-target](https://docs.bazel.build/versions/master/remote-caching.html#exclude-specific-targets-from-using-the-remote-cache). I think for a local shared cache, the default of including non-path dependencies might be a good start?

---

_[View the full topic](https://internals.rust-lang.org/t/idea-cargo-global-binary-cache/9002)._