Open ehuss opened 4 years ago
I guess I'll have some crates to be frequently rebuild because I put the target directory at the same place for all projects (to reuse across projects as well as put cache separate from important data).
Linux users are somewhat unique because they have btrfs/zfs/lvm snapshots and rsync.
Cargo has some inconsistent behavior on whether or not it embeds a hash in the filename for executables. #8329 just changed it for macOS, and @joshtriplett pointed out we might want to choose a more consistent behavior across all platforms. Details are elaborated in https://github.com/rust-lang/cargo/blame/de31a3498dcf1641eaa619988df96321c66d2f8b/src/cargo/core/compiler/context/compilation_files.rs#L601-L634. In general, executables on Windows and macOS do not have a hash, and other platforms do. This is primarily because of embedded paths to their external debug information.
One downside of not including the hash is that Cargo is unable to cache multiple copies of the same executable. This can happen with different features and different rustc versions.
Another thing to consider is the impact on reproducible builds, where the filename may get embedded in some scenarios (needs some investigation).
Here are a few options:
deps/bin-foo-64db4e4bf99c12dd/foo
). I can't remember, but that may still be a problem on Windows which embeds an absolute path to the pdb file.I'd probably lean towards 1, but I would like to get some experience with the new macOS behavior for at least a few months to see how annoying it might be.
There's also some discussions of supporting split-debuginfo on Linux (https://github.com/rust-lang/rust/issues/34651). I have zero experience with that, but I'm curious if that would be impacted in a similar way.