Error on `cargo clean` when target directory is a mount point

[nandesu-utils]

Problem

I am using custom script to create a target and mount a tmpfs into it but when I run usual cargo clean it tries to delete the directory which fails with error due to busy resource since a mount point can't be deleted without unmounting first.

Proposed Solution

I think having a flag that controls whether the user would want to delete the /target directory when cleaning is going to help.

Notes

No response

[epage]

Would you be willing to look into how other build systems handle this problem?

[nandesu-utils]

Would you be willing to look into how other build systems handle this problem?

What do you mean by that? What should I look for?

Some existing generic build systems for Rust are either badly supported or stalled, but what I need is merely this small flag just not to suppress error code and keep from using rm -r in scripts by using cargo clean instead, especially if the target directory has uncommon path specified.

If there is any problem or I just missed something, please point that out.

[epage]

Would you be willing to look into how other build systems handle this problem?

What do you mean by that? What should I look for?

e.g. go clean

Its both useful to see what we can learn from problems that other build systems have. It also provides an idea of how prevalent the problem is.

[nandesu-utils]

I do not understand what do you mean by that.

Clean command in go is not fully analogous to Cargo's command since there is basically no left over objects remaining in the source directory except for few specific ones; it uses temporary directory for intermediary files and source directory as a target for binary output. Same cmake uses an output target for removing objects on cleaning and I am not sure how it works, barely used cmake though.

About prevalent problems, there was fleet which handled many things by itself but... currently it's unavailable it seems? Considering other build system, say, D's DUB doesn't even remove the target binary as it only cleans the cached files.

I am not sure what kind of things can be learned from cleaning commands in build systems without changing the semantics of how cargo manages building crates. I just think this flag would be useful for small scripts (and so I made a PR and I already have used the custom fork with this PR to assist the building pipeline, and it simplified building; I didn't notice perf regressions too).

[nandesu-utils]

It would be nice if Cargo itself would support using different means for target directory filesystem where build artifacts are located but that's a no-go:

1. This is system-specific, or even environment-specific (sandboxed environments of any kind, mounting is ok on Linux but what about Windows?)
2. This is already implemented in (some way) via build.target-dir which can be put into .cargo/config.toml or via an argument --config build.target-dir and do it manually depending on the environment.

I found that (2.) was just not as simple as some quick manual mount and forgetting about it until next reboot and just pressing arrow keys until I find cargo clean --keep-directory; it could be shortened to --keep-dir though.

So this is why I suggested such a flag; other build systems either use their own means for temporary files already in temporary folders or provide same or less features as Cargo does right now relative to this problem.

[ehuss]

A few questions and comments on this:

• What is the concern with cargo generating an error when running cargo clean if it has otherwise successfully removed all files?
• Would other proposals like RFC: Templating CARGO_TARGET_DIR to make it the parent of all target directories rfcs#3371 or Remap target dir #11156 address your use case?
• The team discussed one option of having cargo either warn or ignore if it fails to delete the top-level directory. There was some concern that this could be too magical, breaking other automation, or possibly hiding real issues.

[poliorcetics]

As I understand the issue, rust-lang/rfcs#3371 would resolve this, I would appreciate comments on it if you think it doesn't @nandesu-utils :)

[epage]

I've updated the title to focus on the end-user problem, rather than one specific solution.