workspace cargo build --bin [target] error

[Bert-Proesmans]

Building a specific bin target with cargo from a workspace root does not work.

I tried this:

• Have a cargo workspace with two library crates
• Both crates have autobins = false, but one crate has a manual [[bin]] entry
• Try to compile the specific bin from the workspace root; cargo build --bin [target]

I expected to see this happen: The binary target gets built.
Because the test-subcommand works as expected..

Instead, this happened: error message
-> error: no bin target named [target]

I'm using cargo 1.27.0 (1e95190 2018-05-27) - Stable toolchain

Note:
cargo build --bins DOES work and compiles all binaries, effectively that one target binary.
changing work-directory into sub crate with bin and running cargo build --bin [target] DOES work and compiles the selected binary.

[alexcrichton]

Definitely sounds like a bug!

[ehuss]

Is it expected that without -p that specifying targets would work? If there are multiple packages with a bin named "foo" and you ran cargo build --bin foo would it build all of them matching that name? Similarly, cargo build --lib would skip any package without a lib?

[Bert-Proesmans]

@ehuss I deduced the expectation from the cargo help page about build.
This expectation is similar to cargo test [filter] on virtual workspaces: compiles and executes all tests which have [filter] in their name.

In my opinion clashes don't matter because there is no first-and-only expectation of the effect, contrary to the run subcommand.
Talking about the run-subcommand; it's not allowed to be executed on a virtual manifest. Clashes are avoided because a single crate is not expected to have multiple bin targets with the same name.
To be more in line with the run command cargo build --bin on a virtual manifest shouldn't be allowed either. Optionally tell the user to specify a specific package with -p within the error message.
There is still cargo build --bins if building all bin targets becomes necessary.

Going forward i believe the following options are available.
Note: I talk about these options in the context of executing them on a virtual manifest.

• Fix the current build --bin subcommand to correctly select matching targets from available ones
• Disallow usage of build --bin subcommand, just like run --bin

[alexcrichton]

@ehuss it's true yeah there can be conflicts, I'd imagine though we could do something like run the bin foo if there's only one and error if there's multiple (asking for -p to disambiguate). I agree with @Bert-Proesmans that it's a little inconsistent right now to accept --bins but not --bin foo (where we can)

[ehuss]

@alexcrichton if you want to assign this to me, I'll take a look at it soon.

EDIT: or maybe github doesn't allow that 😦

[alexcrichton]

Sure thing, thanks @ehuss!

[dwijnand]

You should be assignable now you're on the team! 😁