Document that -s followed by -f does not work as expected unless using -Zmtime-on-use

Ploppz commented 2 years ago

https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#mtime-on-use

What I mean is, in the README you should mention that this flags needs to be set. It takes a while to debug why it doesn't work, until finally someone on Discard could point me to that flag.

Ploppz commented 2 years ago

Btw: I didn't try that yet. I'm on linux. And the behaviour I've seen without that flag at least, is:

let's say build is cached. Then the next cargo build doesn't touch the files used
then the next -f will remove everything
so next cargo build rebuilds everythin
so that the next -f doesn't remove anything we need
so that the next cargo build has everything cached.

And so it alternates.

wagenet commented 2 years ago

@holmgr ping

polarathene commented 4 months ago

As a side effect of -Z mtime-on-use wouldn't other software potentially get a negative effect? If you were to derive a hash based on files in the target directory, IIRC adjusting file attributes can affect some operations like that? So while it may address one issue, it may cause regressions elsewhere?

I haven't looked into how the tool here works, but if it cares about access time, there is atime with the overhead to update files when they're accessed / read. Although it's a common practice to see advice of mounting with noatime where that'd never update, I don't know if updating a file with mtime is a great workaround either 😅

It's been a while since the last comment here, Rust nightly is working on it's own GC (I don't think it handles target directory yet), where they're using an SQLite database to track cache items instead.

I suppose it'd update that db in a similar way to how it'd approach -Z mtime-on-use, and once ready you'd have an official tool for this instead 👍

holmgr / cargo-sweep

Document that -s followed by -f does not work as expected unless using -Zmtime-on-use #62