Allow limiting required crate-types of dependencies

[mystor]

Problem

When depending on a crate which declares it supports multiple crate types in its [lib] section, cargo will always build all of the specified crate types when building the dependency. This means that a crate which specifies something like the following in its Cargo.toml will always build a cdylib and staticlib when built as a dependency, even if we're only going to be using the normal lib dependency.

[lib]
crate-type = ["cdylib", "staticlib", "lib"]

This leads to wasted effort building unnecessary artifacts for dependencies, and can also lead to issues when the configuration used to build the lib would cause building the cdylib or staticlib to fail to link for whatever reason (e.g. due to linker flags).

Proposed Solution

It would be nice if there was a way to specify which crate types you are depending on from your dependencies when declaring a dependency in Cargo.toml, similar to how you can specify required feature flags.

I imagine this acting in a similar way to features, where when a dependency is declared without a crate-type specification, it implicitly requires the crate types from the dependency's Cargo.toml, and a dependency with crate-type only requires the specified crate types.

This might look something like the following:

[dependencies.mycrate]
version = "1.0.0"
crate-type = ["lib"]

Notes

There may be some overlap between this and other work for artifact dependencies (#9096), although I am not familiar enough with the work in that area to know if it already covers this use-case.

[weihanglo]

Artifiact dependencies might not help if you just want to limit dependency to only build rlib. With the current implementation, you can only specify bin, cdylib, and staticlib.

If I were you, I may contact the author of my dependency crate. Tell them there is a newly stabilized flag cargo rustc --crate-type, which could build any crate-type on demand. See how hyper uses --crate-type to remove crate-type = […] in its Cargo.toml and speedup their build.

[mystor]

cc @BurntSushi I suppose, as I noticed this when trying to link rure as an rlib (which was added as a crate type in rust-lang/regex#909).

It seems odd to have a crate like that which is only intended to provide a c api not marked as crate-type = ["cdylib", "staticlib", ...], but I suppose it would be an option which would fix my issue. Not sure what other side effects it would have.

[BurntSushi]

Yeah I'm not sure what to make of this. I don't get many complaints about rure compile time, so this particular problem isn't really on my radar.

[glandium]

To me, the core problem is that if crate A depends on crate B, the only thing that cargo can handle is B being a rlib and using it to build A. If B is a cdylib or a staticlib, cargo won't handle the situation. So really, the only thing cargo can handle is B being a rlib. Now, if you're building A, why does cargo care to build something else than the rlib? would be the issue IMO.