Cache libstd artifacts between projects

[jyn514]

Right now, cargo rebuilds std for each target directory:

; cargo build -Z build-std --target x86_64-unknown-linux-gnu
   Compiling compiler_builtins v0.1.91
   Compiling core v0.0.0 (/home/jyn/.local/lib/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
...
   Compiling inner v0.1.0 (/home/jyn/src/example/inner)
    Finished dev [unoptimized + debuginfo] target(s) in 8.43s
; cd ..
; c b -Z build-std --target x86_64-unknown-linux-gnu
   Compiling compiler_builtins v0.1.91
   Compiling core v0.0.0 (/home/jyn/.local/lib/rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
...
   Compiling inner v0.1.0 (/home/jyn/src/example/inner)
   Compiling example v0.1.0 (/home/jyn/src/example)
    Finished dev [unoptimized + debuginfo] target(s) in 8.63s

It would be nice to cache this (in CARGO_HOME/.cargo?) so that it's not duplicated. This should follow all of cargo's normal caching rules, so e.g. changing RUSTFLAGS or profile.dev.debug would rebuild.

[jyn514]

@rustbot claim

[rustbot]

Error: This repository is not enabled to use triagebot.
Add a triagebot.toml in the root of the default branch to enable it.

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

[ehuss]

I just want to warn you that this is a huge change that has some history (not to dissuade you, just to clarify what it means). There's an overview of the tasks at rust-lang/cargo#11429 (comment). Each one is quite large and needs some design work.

[Lokathor]

I hope this doesn't clog up my $user/.cargo directory with a bunch of junk. That is on my rather small C drive, compared to my larger D drive where my rust projects live.

I update nightly more often than I start new cross-build projects, so I don't want the libstd of a bunch of nightly versions hanging out in my C drive.

So hopefully this will include something to make it be cleaned by cargo clean or cleaned by rustup update or just be something that can be turned off entirely.

[jyn514]

Hmm, good point, I hadn't thought about how the cache would grow without bound.

So I don't lose it, my work so far is https://github.com/rust-lang/cargo/compare/master...jyn514:cargo:build-std-cache?expand=1

[Lokathor]

This is marked "plan before stabilization", but I don't think it should be a stabilization blocker.

It would be nice to have, but caching stuff more often seems like a quality of implementation detail, not an essential part of build-std.