4 ms·

What’s stopping cargo from storing libraries in one global directory(via hash or whatever), to be re-used whenever needed?

jakkos 1y ago
You can: https://github.com/mozilla/sccache https://github.com/mozilla/sccache
- preciousoo 1y ago
  Oh this is amazing, looks simple to set up too. Thanks!
  - kstrauser 1y ago
    It's a game-changer, especially on my slower machines like Raspberry Pis. They can use every advantage they can get.
epage 1y ago
That work is being tracked in https://github.com/rust-lang/cargo/issues/5931 https://github.com/rust-lang/cargo/issues/5931 Someone has taken up the work on this though there are some foundational steps first. 1. We need to delineate intermediate and final build artifacts so people have a clearer understanding in `target/` what has stability guarantees (implemented, awaiting stabilization). 2. We then need to re-organize the target directory from being organized by file type to being organized by crate instance. 3. We need to re-do the file locking for `target/` so when we share things, one cargo process won't lock out your entire system 4. We can then start exploring moving intermediate artifacts into a central location. There are some caveats to this initial implementation - To avoid cache poisoning, this will only items with immutable source that and an idempotent build, leaving out your local source and stuff that depends on build scripts and proc-macros. There is work to reduce the reliance on build scripts and proc-macros. We may also need a "trust me, this is idempotent" flag for some remaining cases. - A new instance of a crate will be created in the cache if any dependency changes versions, reducing reuse. This becomes worse when foundation crates release frequently and when adding or updating a specific dependency, Cargo prefers to keep all existing versions, creating a very unpredictable dependency tree. Support for remote caches, especially if you can use your project's CI as a cache source, would help a lot with this.

jakkos 1y ago

You can: https://github.com/mozilla/sccache https://github.com/mozilla/sccache

preciousoo 1y ago
Oh this is amazing, looks simple to set up too. Thanks!
- kstrauser 1y ago
  It's a game-changer, especially on my slower machines like Raspberry Pis. They can use every advantage they can get.

epage 1y ago

That work is being tracked in https://github.com/rust-lang/cargo/issues/5931 https://github.com/rust-lang/cargo/issues/5931 Someone has taken up the work on this though there are some foundational steps first. 1. We need to delineate intermediate and final build artifacts so people have a clearer understanding in `target/` what has stability guarantees (implemented, awaiting stabilization). 2. We then need to re-organize the target directory from being organized by file type to being organized by crate instance. 3. We need to re-do the file locking for `target/` so when we share things, one cargo process won't lock out your entire system 4. We can then start exploring moving intermediate artifacts into a central location. There are some caveats to this initial implementation - To avoid cache poisoning, this will only items with immutable source that and an idempotent build, leaving out your local source and stuff that depends on build scripts and proc-macros. There is work to reduce the reliance on build scripts and proc-macros. We may also need a "trust me, this is idempotent" flag for some remaining cases. - A new instance of a crate will be created in the cache if any dependency changes versions, reducing reuse. This becomes worse when foundation crates release frequently and when adding or updating a specific dependency, Cargo prefers to keep all existing versions, creating a very unpredictable dependency tree. Support for remote caches, especially if you can use your project's CI as a cache source, would help a lot with this.