cargo -h is misleading when building multiple bin with a src/main.rs

[Cobrand]

if you have

src/
    main.rs
    bin/
        other_bin.rs
        other_bin2.rs

cargo run will say that it requires that a project have one executable, "use the --bin option to specify which one to run".

However cargo -h clearly says that cargo run "Build and execute src/main.rs"

So why should I have to specify --bin if I want to build src/main.rs ? Is this the intended behaviour ? If it isn't, well it's probably a bug. If it is, maybe some rewording in cargo -h will help, and maybe add an option in Cargo.toml along "[[bin]]" which would allow you to say which bin is built by default (like a field default = true). I think that no matter how many binaries you have, if you have a src/main.rs, it should build that by default.

[alexcrichton]

Ah sounds like it should the small docs there should be updated!

[Cobrand]

I'm fine with this being a doc problem, but should cargo behave that way ? I don't think it makes much sense that someone has to type cargo run --bin crate-name when there is an explicit src/main.rs in the crate and everything else is in src/bin/. If I wanted to be explicit about it, I would have moved everything in src/bin/.

I personally think it makes more sense to run by default src/main.rs even though other binaries' mains are in src/bin/; is there a reason for it not being like that ?

[alexcrichton]

To Cargo at least any bin target is the same as the other, whether it's src/main.rs or src/bin/foo.rs they're treated equally

[Cobrand]

Is this because of technical reasons (like, it was the easiest way to implement this) or because someone decided that it would explicitly be like that because of some X reason ?

If the latter, I think I will submit a PR at some point in the future allowing to compile src/main.rs when running only cargo run. If this PR isn't allowed, I'll do another one allowing a field "default" under [[bin]] allowing it to be run by default when no --bin <bin_name> is specified. Does that look ok ?

[alexcrichton]

This basically just fell out of the initial implementation. It wasn't really decided either for or against.

@rust-lang/tools, thoughts about this issue?

[Cobrand]

Since there are no objections, I take it that any PR about this issue won't be closed right away ?

[alexcrichton]

I might recommend holding off on sending a PR just yet until we get some more opinions. I'd personally at least prefer to treat all binaries as equal as opposed to making some special over others.