It is not possible to specify a default binary

[JanLikar]

I think it would be really great if one would be able to specify a default binary in Cargo.toml, so cargo run could be used without --bin argument when there are more binaries in a crate.

[steveklabnik]

👍 , with the default default being set to src/main.rs

[JanLikar]

Do you think something like default-bin in [package] would be ok?

[alexcrichton]

I'd be a little hesitant to move on this just yet. For example there are other questions I'd have such as:

• Should there also be a default test binary? Default bench binary?
• Does this interact with commands like cargo rustc and cargo rustdoc where the default takes precedence over other targets?
• Does this interact with cargo install where the default is the only one installed unless otherwise specified?

I'd want to flesh this out a bit more and see how it fits into the whole Cargo picture before landing it. FOr now --bin foo doesn't seem too costly at least for something that's largely only used during development.

[JanLikar]

I agree, I will think this through.

[jadencarver]

+1

[andreastt]

I think having a run or default-run option, akin to build, under [package] would be a good idea for the reason that one might implement a program with “subcommands” as multiple binaries with the default program as the sub-program dispatcher.

Using git(1) as an example:

• /usr/bin/git
• /usr/lib/git-core/git-commit
• /usr/lib/git-core/git-diff

When using git commit in the shell this passes "commit" as a string to /usr/bin/git, which ends up calling /usr/lib/git-core/git-commit with more flags.

Hypothetically imaging implementing this using cargo, calling cargo run -- commit is more concise than cargo run --bin git-commit -- -c some=flag.

[zimond]

If developing using VSCode, the RustyCode plugin requires only one binary to be specified. So I think this feature could be useful.

[huytd]

What is the status of this issue right now? It is very helpful if you have multiple binaries in a project!

[RalfJung]

Should there also be a default test binary? Default bench binary?

I feel like test binaries are a very separate thing anyway, and cargo test per default runs all of them (right?). I never used bench, but it seems similar to test?

Does this interact with commands like cargo rustc and cargo rustdoc where the default takes precedence over other targets?
Does this interact with cargo install where the default is the only one installed unless otherwise specified?

I think this should affect cargo run only. It could be called "default-run" or so, like @andreastt suggested?

[sunjay]

What about something in the [[bin]] configuration like the following?

[[bin]]
name = "my-default-executable"
default = true

That fits into the existing way to configure binaries and will support future additions as well since it isn't as "one-off" as "default-run". :)

[mcobzarenco]

@sunjay I reckon @JanLikar's suggestion:

Do you think something like default-bin in [package] would be ok?

is preferable as it disallows in its representation having more than one default.

[GildedHonour]

what's the status of this, is it already possible?

[dhbradshaw]

An example usage of this now-merged feature is here:

https://stackoverflow.com/questions/51785457/how-can-i-specify-which-crate-cargo-run-runs-by-default-in-the-root-of-a-cargo

[vladikoff]

TL;DR it works this way:

[package]
name = "namehere"
...
default-run = "binaryname"

[[bin]]
name = "binaryname"
path = "src/main.rs"

[[bin]]
name = "somethingelse"
path = "src/somethingelse.rs"