Open tae-soo-kim opened 1 year ago
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.
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.
isn't the official name for these "targets"? a crate can contain multiple targets, and each target may be composed of several modules.
Crates and build targets (as opposed to platform targets) are the same thing. Packages contain multiple crates. crates.io and .crate
files cause a lot of confusion on this point.
See https://doc.rust-lang.org/cargo/appendix/glossary.html#crate
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
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:or
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: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 inCargo.toml
.