Per-crate linking option in Cargo manifest

[tae-soo-kim]

Problem

One Rust package may contain a single library crate and multiple binary crates. If only one binary crate needs to link with a C native library, then it doesn't quite make sense to link that native library with the library crate, because

1. The library crate itself doesn't need it, nor do other binary crates.
2. Users of the package do not clearly see which native libraries are needed for which crate.

Currently the only way to configure per-crate linking option seems to be using cargo:rustc-link-arg-bin=BIN=FLAG. This requires some effort in the build script, and still doesn't show native library dependencies in documented format.

Proposed Solution

It would be much nicer if each crate lists its own linking dependencies in Cargo.toml like this:

[lib]
name = "foo"
links = "foodeps"

[[bin]]
name = "bar"
links = "bardeps"

[[bin]]
name = "baz"
links = "bazdeps"

or

[lib]
name = "foo"
rustc-link-lib = "foodeps"

[[bin]]
name = "bar"
rustc-link-lib = "bardeps"

[[bin]]
name = "baz"
rustc-link-lib = "bazdeps"

Programmers won't need #link attribute or cargo:rustc-link-lib=LIB build script instruction in many use cases.

Notes 1

Currently Cargo.toml may contain these fields to override build scripts:

[target.x86_64-unknown-linux-gnu.foo]
rustc-link-lib = ["foo"]
rustc-link-search = ["/path/to/foo"]

However this applies to whole package not per crate.

Notes 2

Currently, Cargo on cargo:rustc-link-lib passes -l <lib> to rustc when compiling the lib crate. What I'm looking for is Cargo passing -l <lib> to bin crates on a similar build script instruction or a bin-crate option in Cargo.toml.

[epage]

As a heads up, we've been talking about shifting the focus to separate bin and lib packages though no decision has been made at this time.

[tae-soo-kim]

As a heads up, we've been talking about shifting the focus to separate bin and lib packages though no decision has been made at this time.

If I were designing the Rust package/crate system, I wouldn't think in bin/lib but only modules. The current lib.rs is a module. The current main.rs is also a module. One module can contain another module (as is the case now). If a module has fn main() then it can be compiled into a binary and run. A crate is a module designated as a translation unit, that is, compiled on its own. The manifest Cargo.toml lists which modules are designated as crates. And rustc still works without Cargo: just specify the module to be compiled as a crate in command line arguments.

Then there will be no more questions like cargo new --lib --bin. cargo new gives a top-level mod.rs, the root module/crate of the new package. In my opinion mod.rs is way nicer than lib.rs or main.rs. We don't have to remember special file names (other than mod.rs), and the crate can now be easily attached as a sub-module in a different crate. This makes the root module relocatable, among other benefits, without losing the advantage of freely organizing code.