Pakiet Rust zawierający zarówno bibliotekę, jak i plik binarny?

Chciałbym stworzyć pakiet Rusta zawierający zarówno bibliotekę wielokrotnego użytku (w której zaimplementowana jest większość programu), jak i plik wykonywalny, który z niej korzysta.

Zakładając, że nie pomyliłem żadnej semantyki w systemie modułów Rusta, jak powinien Cargo.tomlwyglądać mój plik?

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 <[email protected]>"]

[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();
}

Możesz również po prostu umieścić źródła binarne, src/bina pozostałe źródła src. Możesz zobaczyć przykład w moim projekcie . Nie musisz Cargo.tomlw ogóle modyfikować swojego , a każdy plik źródłowy zostanie skompilowany do postaci binarnej o tej samej nazwie.

Konfiguracja drugiej odpowiedzi jest następnie zastępowana przez:

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

Cargo.toml

[package]
name = "example"
version = "0.0.1"
authors = ["An Devloper <[email protected]>"]

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));
}

I wykonaj to:

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

Dodatkowo możesz po prostu utworzyć plik, src/main.rsktóry będzie używany jako plik wykonywalny defacto. Niestety jest to sprzeczne z cargo docpoleceniem:

Nie można udokumentować pakietu, w którym biblioteka i plik binarny mają taką samą nazwę. Rozważ zmianę nazwy jednego lub oznaczenie celu jakodoc = false

Alternatywnym rozwiązaniem jest nie próbowanie upychania obu rzeczy w jednym pakiecie. W przypadku nieco większych projektów z przyjaznym plikiem wykonywalnym bardzo przyjemnie jest używać obszaru roboczego

Tworzymy projekt binarny, który zawiera w sobie bibliotekę:

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

Cargo.toml

Używa [workspace]klucza i zależy od biblioteki:

[package]
name = "the-binary"
version = "0.1.0"
authors = ["An Devloper <[email protected]>"]

[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)
}

I wykonaj to:

$ 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)

Ten program ma dwie duże korzyści:

1. Plik binarny może teraz używać zależności, które mają zastosowanie tylko do niego. Na przykład możesz dołączyć wiele skrzynek, aby poprawić wygodę użytkownika, takich jak parsery wiersza poleceń lub formatowanie terminala. Żadne z nich nie „zainfekuje” biblioteki.

2. Przestrzeń robocza zapobiega zbędnym kompilacjom każdego składnika. Jeśli uruchomimy cargo buildzarówno w katalogu, jak mylibraryi the-binary, biblioteka nie zostanie zbudowana dwukrotnie - jest współdzielona między oba projekty.

Możesz umieścić lib.rsi main.rsdo folderu źródeł razem. Nie ma konfliktu, a ładunek zbuduje obie rzeczy.

Aby rozwiązać konflikt dokumentacji, dodaj do Cargo.toml:

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