Hello all! I'm very new to rustc/cargo development so my apologies if some of this doesn't make sense/wouldn't work out. Welcome to yet another post about caching! I was experimenting with implementing a system-wide crate cache in cargo and ran into some issues that make cargo-compiled crates not very cache friendly. I did some thinking and found some potential solutions. I've made some drawings and and an explanation of some of my solutions. This is just a concept at the moment, so once I get some feedback I will flesh this out into a more detailed RFC for a system wide crate cache and the improvements needed to make this happen. Any feedback would be appreciated!
1 Like
One issue is that due to monomorphisation and inlining the bodies of generic and #[inline] functions are part of the "public API" that would need to be hashed. Including those is very likely to cause the hash to change between basically any version update.
I think I've seen mentioned a proposal that a crate should track what details of its dependencies it actually cares about more accurately. With something like that it could be possible that B 1.0.0 when built against C 1.0.0 and B 1.0.0 when built against C 1.0.1 produce identical artifacts, that could be deduplicated in the cache store; but you will probably still need to build B 1.0.0 against C 1.0.1 once to verify that nothing in what it uses has changed.
This topic was automatically closed 540 days after the last reply. New replies are no longer allowed.