Pacote de ferrugem com uma biblioteca e um binário?

Eu gostaria de criar um pacote Rust que contenha uma biblioteca reutilizável (onde a maior parte do programa é implementada) e também um executável que o utilize.

Supondo que não tenha confundido nenhuma semântica no sistema do módulo Rust, como deve ser meu Cargo.tomlarquivo?

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

Você também pode colocar fontes binárias src/bine o restante das fontes src. Você pode ver um exemplo no meu projeto . Você não precisa modificar o seu Cargo.toml, e cada arquivo de origem será compilado em um binário de mesmo nome.

A configuração da outra resposta é substituída por:

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

E execute:

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

Além disso, você pode apenas criar um src/main.rsque será usado como executável padrão. Infelizmente, isso entra em conflito com o cargo doccomando:

Não é possível documentar um pacote em que uma biblioteca e um binário tenham o mesmo nome. Considere renomear um ou marcar o destino comodoc = false

Uma solução alternativa é realmente não tentar empilhar as duas coisas em um único pacote. Para projetos um pouco maiores com um executável amigável, achei muito bom usar um espaço de trabalho

Criamos um projeto binário que inclui uma biblioteca dentro dele:

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

Cargo.toml

Isso usa a [workspace]chave e depende da biblioteca:

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

E execute:

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

Existem dois grandes benefícios para esse esquema:

1. O binário agora pode usar dependências que se aplicam apenas a ele. Por exemplo, você pode incluir várias caixas para melhorar a experiência do usuário, como analisadores de linha de comando ou formatação de terminal. Nada disso "infectará" a biblioteca.

2. O espaço de trabalho evita construções redundantes de cada componente. Se rodarmos cargo buildno diretório mylibrarye the-binary, a biblioteca não será construída nas duas vezes - será compartilhada entre os dois projetos.

Você pode colocar lib.rse main.rsna pasta de fontes juntos. Não há conflito e a carga construirá as duas coisas.

Para resolver conflitos de documentação, adicione ao seu Cargo.toml:

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