Pacchetto Rust con una libreria e un binario?

Vorrei creare un pacchetto Rust che contenga sia una libreria riutilizzabile (dove viene implementata la maggior parte del programma), sia un eseguibile che lo utilizza.

Supponendo che non ho confuso alcuna semantica nel sistema del modulo Rust, come dovrebbe essere il mio Cargo.tomlfile?

Tok:tmp doug$ du -a

8   ./Cargo.toml
8   ./src/bin.rs
8   ./src/lib.rs
16  ./src

Cargo.toml:

[package]
name = "mything"
version = "0.0.1"
authors = ["me <me@gmail.com>"]

[lib]
name = "mylib"
path = "src/lib.rs"

[[bin]]
name = "mybin"
path = "src/bin.rs"

src / lib.rs:

pub fn test() {
    println!("Test");
}

src / bin.rs:

extern crate mylib; // not needed since Rust edition 2018

use mylib::test;

pub fn main() {
    test();
}

Puoi anche inserire semplicemente le fonti binarie src/bine il resto delle tue fonti src. Puoi vedere un esempio nel mio progetto . Non è necessario modificarlo Cargo.tomlaffatto e ogni file di origine verrà compilato in un file binario con lo stesso nome.

La configurazione dell'altra risposta viene quindi sostituita da:

$ tree
.
├── Cargo.toml
└── src
    ├── bin
    │   └── mybin.rs
    └── lib.rs

Cargo.toml

[package]
name = "example"
version = "0.0.1"
authors = ["An Devloper <an.devloper@example.com>"]

src / lib.rs

use std::error::Error;

pub fn really_complicated_code(a: u8, b: u8) -> Result<u8, Box<Error>> {
    Ok(a + b)
}

src / bin / mybin.rs

extern crate example; // Optional in Rust 2018

fn main() {
    println!("I'm using the library: {:?}", example::really_complicated_code(1, 2));
}

Ed eseguilo:

$ cargo run --bin mybin
I'm using the library: Ok(3)

Inoltre, puoi semplicemente creare un file src/main.rsche verrà utilizzato come eseguibile defacto. Sfortunatamente, questo è in conflitto con il cargo doccomando:

Impossibile documentare un pacchetto in cui una libreria e un file binario hanno lo stesso nome. Valuta di rinominarne uno o di contrassegnare il target comedoc = false

Una soluzione alternativa è quella di non provare a raggruppare entrambe le cose in un unico pacchetto. Per progetti leggermente più grandi con un eseguibile amichevole, ho trovato molto bello usare uno spazio di lavoro

Creiamo un progetto binario che include una libreria al suo interno:

the-binary
├── Cargo.lock
├── Cargo.toml
├── mylibrary
│   ├── Cargo.toml
│   └── src
│       └── lib.rs
└── src
    └── main.rs

Cargo.toml

Questo utilizza la [workspace]chiave e dipende dalla libreria:

[package]
name = "the-binary"
version = "0.1.0"
authors = ["An Devloper <an.devloper@example.com>"]

[workspace]

[dependencies]
mylibrary = { path = "mylibrary" }

src / main.rs

extern crate mylibrary;

fn main() {
    println!("I'm using the library: {:?}", mylibrary::really_complicated_code(1, 2));
}

MyLibrary / src / lib.rs

use std::error::Error;

pub fn really_complicated_code(a: u8, b: u8) -> Result<u8, Box<Error>> {
    Ok(a + b)
}

Ed eseguilo:

$ cargo run
   Compiling mylibrary v0.1.0 (file:///private/tmp/the-binary/mylibrary)
   Compiling the-binary v0.1.0 (file:///private/tmp/the-binary)
    Finished dev [unoptimized + debuginfo] target(s) in 0.73 secs
     Running `target/debug/the-binary`
I'm using the library: Ok(3)

Ci sono due grandi vantaggi in questo schema:

1. Il binario ora può usare dipendenze che si applicano solo ad esso. Ad esempio, è possibile includere molte cassette per migliorare l'esperienza dell'utente, come i parser della riga di comando o la formattazione del terminale. Nessuno di questi "infetterà" la biblioteca.

2. L'area di lavoro impedisce build ridondanti di ciascun componente. Se eseguiamo cargo buildin entrambe le directory mylibrarye the-binary, la libreria non verrà creata entrambe le volte: è condivisa tra entrambi i progetti.

Puoi mettere lib.rse main.rsnella cartella delle fonti insieme. Non c'è conflitto e il carico costruirà entrambe le cose.

Per risolvere il conflitto documentaion aggiungi al tuo Cargo.toml:

[[bin]]
name = "main"
doc = false