Allow --crate-type for binaries

[daxpedda]

Problem

Currently when trying to write cross-platform applications in Rust targeting Web (through Wasm), Android and iOS, users end up having to create a separate library target. Desktop requires bin, Web and Android (APKs) require cdylib and iOS requires staticlib.

There are multiple ways to achieve this:

1. Create a separate library package.
2. Explicitly create a [lib] target, e.g.

   [lib]
   crate-type = ["cdylib", "staticlib"]
   path = "src/main.rs

   This has the downside of superfluously compiling more targets then necessary for specific platforms. E.g. Android doesn't need staticlib but gets both nevertheless when using cargo build --lib. This would be addressed by Support [target.'cfg(...)'.lib] sections #12260.
   Also officially supporting this kind of setup would require removing this warning.
3. Creating an automatic [lib] target by creating a lib.rs file. Which has the same downsides as 2. and would also be addressed by Support [target.'cfg(...)'.lib] sections #12260.

In reality of course all these targets require some form of post processing:

• Web requires post-processing the Wasm file (in the case of wasm-bindgen) and generating an appropriate JS file. This is popularly handled by wasm-pack.
• Android requires generating an APK package, which is popularly done by cargo apk.
• iOS requires going through XCode (I know of cargo dinghy and cargo mobile2 but never tried them).

None of these tools though can circumvent the fact that users have to do some manual work to get the basic build process working. This not only causes every cross-platform project targeting Web and mobile to a have an additional lib.rs, but also examples for popular libraries to require a dedicated one or either not work.

Proposed Solution

Cargo already supports cargo rustc --crate-type type and there are already some tools out there using it, but they all still require a library target.

I don't know why Cargo currently disallows using --crate-type on binary targets, but allowing it would be simple and essentially solve the problem outlined here.

Notes

I stumbled on this limitation in #12260 (comment).
#6351 might be related.

Compiling for Web (through Wasm) actually works with a binary target and doesn't require compiling a cdylib, but it is generally not recommended because Rustc inserts a ton of unnecessary bloat in the resulting Wasm module.
I was told before, by more knowledgeable people then myself, that this is considered a bug in Rustc.

[epage]

The root problem sounds like its the same as #12260, this just discusses an alternative solution. I'm not seeing the value of forking the conversation for that problem to two separate issues for us to coordinate between and lean towards closing this in favor of #12260 where we can talk about several solutions and not just the one proposed with the problem Let us know if there is a reason this should be kept open, rather than discussing it there.