Configurable clean behavior

[tetsuharuohzeki]

Cargo can configure build behavior to build non-rust code. Likewise, we should be able to configure clean behavior to clean up the items which are built by the customized build behavior.

[alexcrichton]

Are you thinking of something like cargo clean foo as an extension to the subcommand, or would you like to have a clean key in the manifest that contains an arbitrary script to run whenever the package is cleaned?

[tetsuharuohzeki]

Are you thinking of something like cargo clean foo as an extension to the subcommand, or would you like to have a clean key in the manifest that contains an arbitrary script to run whenever the package is cleaned?

I think the later one. This request is just to add a custom clean behavior pairing making custom behavior.

[kornelski]

In my build scripts I'm running 3rd party make, and I can't easily control where it puts temporary files, but it has make clean that cleans that up.

---

edit: I've made the make put all stuff in OUT_DIR, which does get cleaned, so I can work with that.

[WiSaGaN]

Since build.rs runs before rustc, a custom clean-up script which runs after current cargo clean would be nice to have.

[sehz]

This feature will be handy +1

[vext01]

I'm also looking for this feature.

In #5078 someone noted that:

If you run the build in OUT_DIR, it'll be cleaned up via a cargo clean.

This might work for you as a workaround until this feature is implemented.

On a semi-related note, I'm starting to feel there are too many places where one can configure things related to cargo: build.rs, Cargo.toml, config.toml.

[stale]

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

• Is this still relevant?
• If so, what is blocking it?
• Is it known what could be done to help move this forward?

Thank you for contributing!

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

[stale]

As I didn't see any updates in 30 days I'm going to close this. Please see the previous comment for more information!

[seamlik]

This feature would be great for projects that incorporate code generators into their building process. Think about wasm-bindgen, or even a Rust version of GObject Introspection.

I suggest reopen it.

[brainstorm]

I would help as well for project that have a C binding library, like rust-htslib:

https://github.com/rust-bio/rust-htslib

Right now the submodule under hts-sys has to be cleaned with a build.rs "make clean", otherwise the crate does not reliably compile across separate runs:

https://github.com/rust-bio/rust-htslib/tree/master/hts-sys

[kairoswater-jason]

I need this for interoperability with a makefile based system to compile a third party C library whose contents and build system I have no control over. When cargo clean is called, I am required to issue the equivalent of a make clean in the third party library's build system

[epage]

Not a fan of stale bot and glad we stopped using it. However, I would have also proposed closing this if I had come across it.

First, I think it could be surprising for users to have cargo remove unconventional paths by convention.

Second, there is the question of how this would be done. If we have to build something to see how to clean it, that feels off. We could have a directive in build.rs and cargo stores this off in target-dir for what should be cleaned but that basically means anything can drop a path in that file to have it removed which feels icky to me (even though build.rs can do all of this on its own).

Third, most of the discussion has not been focused on the circumstances around why this is needed. What are the problems with using OUT_DIR for this and why? @kornelski mentioned third-party Makefiles without customizable build directories. How often does that come up? Does that justify a Cargo change or a patch to those tools? Can it be upstreamed? it seems allowing customizing of the location is a very useful tool. For example, we support that in Cargo!

[kairoswater-jason]

The only thing that is needed for third party build system integration is for build.rs to define a function fn on_clean() and have cargo call on_clean() when cargo clean is issued (ie. it is up to the user to define the behavior, cargo does not need know anything about external builds systems)

The non-customizable third party build system situation is very common in embedded systems and other low level (operating system/kernel type) development applications.

[kornelski]

My comment about Makefiles is so old, that Cargo still supported build="sh make" instead of build.rs.

There may be Makefiles that just dump compiled products into the same directory, but today I'd advise either copying everything to OUT_DIR to make a mess there, or replace the makefile with the cc crate.