Add a new argument "--no-build" to "cargo run"

[KalitaAlexey]

Hello everyone.

Currently if you execute cargo run, Cargo compiles the project at first and then runs it.

I run RLS as cargo run --manifest-path /path/to/RLS/Cargo.toml.

Currently I cannot execute the second instance of RLS because it tries to compile and fails because RLS is already running, hence the executable cannot be deleted.

I need Cargo not to build the project.

I suggest to add a new argument --no-build.

It would be good if Cargo shows a warning indicating that the project is changed, but runs it anyway if it can.

I can implement it myself.

I want to hear your opinions about it.

Thanks

[matklad]

If you want to rerun the executable without rebuilding it, then perhaps you can just run it directly?

Something like cargo build --manifest-path /path/to/RLS/Cargo.toml && /path/to/RLS/target/debug/rls should do the trick.

[KalitaAlexey]

@matklad,
I want the project to be built if it hasn't been built yet.

I suppose I want --no-rebuild argument.

[matklad]

Hm, then perhaps you can check if target/debug/rls exists and run it directly if it does, and run cargo build when it does not? Another option is to run cargo build unconditionally the first time you run RLS.

I am not sure if it is possible to determine the situation when the project has been build, but is not fresh: Cargo is stateless, so it only can check if the set of input files is as fresh as the contents of target.

A simple check like "does target directory exist" can be done outside the Cargo.

[aturon]

I'm going to close this out for the time being; it seems best to start with @matklad's suggested workaround.

[KalitaAlexey]

The approach suggested by @matklad seems more correct to me.

[mimoo]

this would still be useful to emit dep files without compiling anything btw (in order to perform static analysis on the correct files)

[matklad]

@mimoo not sure I understand what you are trying to do, but if you mean depinfo files (.d), then those can't be generated without compiling:

identity_proc_macro! {
  mod foo; // depends on foo.rs, after we expand the macro
}

Usually, cargo check works for cases where one doesn't want to compile "anything" (but still wants, effects of proc macros and build scripts).

[jeffw387]

Just to present a use case, I'm using cargo remote to build a project on another machine then copy the build artifacts back. Using cargo run seems to try to rebuild again on the local machine. One of the dependencies of the project behaves differently if CARGO_MANIFEST_DIR environment variable is set or not, so running the binary directly fails. My workaround for now is manually setting that environment variable when running the binary directly, but I could see it being nice to have a --no-rebuild option for cargo. It could be as simple as just running the binaries if they exist in the target folder and failing if they don't exist.

[MartinKavik]

Another use-case: I want to build the project, then execute some custom commands and then run the the project. This logic is inside a build pipeline (in my case in MoonZoon CLI). Running cargo build and then cargo run is unnecessary slow and multiple build messages in the terminal are confusing for the user.

[coder0xff]

Another use case: I'm building for an embedded platform using the manufacturer's modified Rust fork including Cargo. cargo run is modified to flash and monitor the embedded device's serial out, more complicated than just "run it directly." Because debug symbols make the image too large, I split the symbols into a separate file using objcopy. Alas, cargo run puts the symbols right back in and flashing fails.

P.S. Cargo.toml having a "separate debug symbols" option would be an alternative.