Move `build-dir` out of the workspace to `cargo-cache-home` by default

[epage]

As a follow up to #14125, we've talked about changing the default for build-dir after a sufficient time of it being stabilized so people have a chance to test their builds and tools with it to prepare.

Open questions:

• How long do we need to wait before making the switch over?
  • See #t-cargo > build-dir tool compatibility @ 💬 for a discussion for who all may be affected
• What should the new default be?
  • #16086 moved the build-dir for cargo scripts to "{cargo-cache-home}/build/{workspace-path-hash}" as a proposal for what we should do for this.
  • Note that at https://www.reddit.com/r/rust/comments/1o8l3qq/cargoscript_call_for_testing/njyhipl/, someone asked for a mnemonic to be used to easily identify these build-dirs, like us adding a variable for the name of the directory the workspace is in. Granted, this would also balloon the size of the path

[ahicks92]

I may be being dumb, so apologies, but it is unclear whether this is for cargo script or cargo as a whole. If it is only for cargo script clearly the following does not apply.

Someone will want to at minimum call out very loudly that those of us who are moving our projects to non-system drives need to tweak this if it is changed. Specifically on Windows it is not uncommon to reserve C for the system/installed programs and to do work on other drives. In most programming languages (C++, etc) it is sufficient to just move the repository because the intermediate artifacts are all relative to it.

I also suspect that a lot of people probably do CI setups where they assume their repo is the only thing that needs to be performant, because again that's a pretty normal-ish thing. I know we did at one of my previous jobs.

If I was a new user trying to optimize my builds and my system, this would be a nasty surprise. SO would potentially large directories on a system drive.

I think changing the default is fine, I'm just highlighting that it's a tad unusual and surprising and that use cases which assume that things are under the repository are probably pretty common. Unlike many other changes this doesn't error or anything: it just mysteriously gets slow, and if you are sufficiently unlucky, takes out the system.

[epage]

This proposed change is for all workspaces; cargo scripts already does this.

In a way, this is to help with those situations. Especially with #1734, all cargo caches would be movable with one environment variable to whatever drive works best for them.

[ahicks92]

I'm pointing out that this creates a "once you know, you know" situation. I would be surprised by it if I was in the shoes of a new user coming from either C/C++ or Python. It seems worth it to me to at least voice it, especially since mostly the people who would be affected aren't here. I'm neutral on the actual setting: if you don't change it I'm fine, if you do then I can (presumably) reconfigure it to point at the right drive.

[T-256]

Am I wrong or the title of this issue incorrectly says cache-cache-home instead of cargo-cache-home?

[ranger-ross]

From my perspective I think moving build-dir of the workspace's target dir by default might actually help newcomers to Rust. Currently there is a lot of "stuff" in target which could be a overwhelming to a newcomer that just wants their program they compiled. When they are already busy trying to learn the language this noise can add additional cognitive load. Moving build-dir to a different location would greatly reduce the amount of files that are added to target.