Пакет Rust с библиотекой и двоичным файлом?

Я хотел бы сделать пакет Rust, который содержит как библиотеку многократного использования (где реализована большая часть программы), так и исполняемый файл, который ее использует.

Если я не перепутал семантику в модульной системе Rust, как должен Cargo.tomlвыглядеть мой файл?

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

Вы также можете просто добавить двоичные источники src/binи остальные источники src. Вы можете увидеть пример в моем проекте . Вам не нужно ничего менять Cargo.toml, и каждый исходный файл будет скомпилирован в двоичный файл с тем же именем.

Конфигурация другого ответа затем заменяется на:

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

И выполнить это:

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

Кроме того, вы можете просто создать объект, src/main.rsкоторый будет использоваться в качестве исполняемого файла defacto. К сожалению, это конфликтует с cargo docкомандой:

Невозможно задокументировать пакет, в котором библиотека и двоичный файл имеют одинаковые имена. Подумайте о переименовании или пометке цели какdoc = false

Альтернативное решение - на самом деле не пытаться собрать обе вещи в один пакет. Для проектов чуть большего размера с дружественным исполняемым файлом я нахожу очень полезным использовать рабочее пространство

Мы создаем бинарный проект, который включает в себя библиотеку:

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

Cargo.toml

Это использует [workspace]ключ и зависит от библиотеки:

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

И выполнить это:

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

У этой схемы есть два больших преимущества:

1. Двоичный файл теперь может использовать зависимости, которые применяются только к нему. Например, вы можете включить множество ящиков для улучшения взаимодействия с пользователем, таких как анализаторы командной строки или форматирование терминала. Ни один из них не «заразит» библиотеку.

2. Рабочая область предотвращает избыточные сборки каждого компонента. Если мы запустим cargo buildкак каталог, так mylibraryи the-binaryкаталог, библиотека не будет собрана оба раза - она ​​используется для обоих проектов.

Вы можете положить lib.rsи main.rsв папку источников вместе. Там нет конфликта, и груз будет строить обе вещи.

Для разрешения конфликта документации добавьте в свой Cargo.toml:

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