cargo build should have --force option

[lilyball]

Sometimes I need to force a rebuild of a target, because it compiled successfully but I want to see the generated warnings. It would be convenient if cargo build accepted a --force flag that makes it consider the current target to be dirty even if it's not. This should not force the recompilation of any dependencies.

[alexcrichton]

We do have cargo clean -p <local-pkg> && cargo build, would that suffice for this?

[steveklabnik]

@kballard what do you think about @alexcrichton 's suggestion?

[lilyball]

I suppose that's an acceptable workaround. Since nobody else has requested this, I'll go ahead and close it.

[OJFord]

This isn't particularly discoverable - I didn't try --force (to me that's not quite right for this) but I was looking through cargo build --help for some option to achieve this behaviour.

Has having an alias, such as cargo build --clean, been considered?

My use case isn't regenerating warnings, but developing a compiler plugin, and just wanting to 'run' it again.

[mlindner]

I second this. It's hard, especially for a new user when filing bug reports to figure out how to re-compile everything to show the warnings again.

[dlukes]

I also think it would be worth reopening this, as others have pointed out, this should be more accessible to beginners ("Where have my compiler warnings / clippy lints gone?").

I think the key thing here is to inform the user that some targets are not being compiled at all, explicitly (i.e. as opposed to just not outputting Compiling xyz ...), something like:

Reusing up-to-date compiled targets, run `cargo clean -p <local-pkg> && cargo build`
(`cargo clean && cargo build`) to force recompilation of project (and dependencies).

Whether the message points to the already available solution, or whether a new flag should be added ("run with --force (--force-all)"), is an issue of lesser importance, though personally I would also welcome a less verbose way of achieving this :)

[monperrus]

for the record, cargo build --clean is dead.

now it's cargo clean

[OJFord]

That was a hypothetical example, it didn't exist.

[lilyball]

I'm going to reopen this issue, as a colleague has recently informed me that decreasing the optimization level for a package does not rebuild it (whereas increasing it does; I do realize that this makes sense in most cases). As the reason for decreasing was to test compilation time of the package in question, this feature actually got in the way and a cargo build --force (or perhaps --rebuild) flag would have helped.

I have a vague recollection that at some point in the past, cargo clean -p <pkgid> did not necessarily restrict itself to just the package in question but may have cleaned more. I don't know if that's true or I'm misremembering, and I hope that's not the case today, but it does make me a bit leery of the idea of saying "clean and then rebuild". In addition, I'm assuming that cargo clean -p <pkgid> will clean the package for all profiles which may be undesirable, whereas a cargo build --force would not.

[weihanglo]

… a colleague has recently informed me that decreasing the optimization level for a package does not rebuild it…

Thanks for raising the awareness. I had a hard time reproducing it. There are several ways that can contribute to optimization levels. Do you have a reproducer at hand? I've used the follow command and it did recompile. Like

cargo b --config 'profile.dev.opt-level = 1'
cargo b --config 'profile.dev.opt-level = 2'
cargo b --config 'profile.dev.opt-level = 3'

I'm assuming that cargo clean -p <pkgid> will clean the package for all profiles which may be undesirable,

You could use --profile to specify a profile to clean all artifacts under it.

cargo clean --profile dev

cargo clean -p <pkgid> did not necessarily restrict itself to just the package in question but may have cleaned more.

This sounds like a bug. And the other two as well. I'd suggest let's focus on the problem first before diving into the solution space. Would you be willing to open new issues if you can reproduce them? Thank you in advance!

[lilyball]

@weihanglo I did not test it myself, but AIUI my colleague was overriding the opt-level for a specific package dependency and then triggering a rebuild.

[DarthB]

I also ended up using cargo clean && cargo build a lot in my current project that provides a wrapper for C/C++. Whereas in my case it is related to foreign function interface (ffi) to C/C++ world and keeping the rust library part on sync as somehow changes are not detected by cargo.

Is there a way to just clean/rebuild the own crate without all dependencies? In good old Visual Studio there was a "Rebuild Project" - "Rebuild Solution" command and I would love if there is something similar for cargo.

In the project, I'm working at the moment cargo is called by CMake to build dlls/static libs that than are imported by a C/C++ code base. I'm already using some workarounds, e.g. using [[example]] to get a "staticlib" and "cdylib" output for the same ffi code. And I often use cargo clean && cargo build --all-targets to ensure that changes are synced to the C/C++ side. (see a related issue regarding cdylib and cargo)

[Eh2406]

Have you tried cargo clean -p [name of your package]?

[epage]

Since this wasn't explicitly said, the main motivation for this has been resolved (warnings). The warnings are now tracked and re-reported even when a rebuild doesn't happen.

[epage]

The cargo team discussed this and we are in favor of closing this.

The original motivation as been resolved now that cargo captures and replays warnings. We have the solution of cargo clean for when there are bugs or other issues needing a rebuild.