it-swarm-ja.com

lib.rsファイルとmain.rsファイルの両方を含むクレートを公開する

Rustブックの Importing External Crates セクションで、作成者は既存のライブラリプロジェクトにmain.rsファイルを作成します。ランダムに一連のクレートをピックアップしました crates.io から、それらの構造を調べたところ、lib.rsファイルとmain.rsファイルの両方を含むプロジェクトが見つかりませんでした。そのため、両方のファイルがlibraryプロジェクトがcrates.ioでホストされていますか、それとも貧弱なスタイルと見なす必要がありますか?

より明確にするために、私は、コミュニティと共有するように設計されたライブラリを開発することについて尋ねています。ライフサイクルが数日ある実行可能ファイルについてではありません。 Cargoの testing 機能を認識しているため、main.rsをライブラリに追加する目的はテストではありません。ライブラリクレートのmain.rsがライブラリにどのように関連付けられるべきかの良い例は、curlコマンドラインツールがlibcurlライブラリにどのように関連付けられるかです。私の考えでは、cargo buildがデフォルトで実行可能ファイルをビルドするプロジェクトがあると便利ですが、すべての機能をライブラリとしてインポートできます。

5
Sergey

バイナリとライブラリ(curllibcurlの例など)を含むクレートを作成する最も簡単な方法は、プロジェクトに_src/bin_フォルダーを作成し、ファイルを配置することですバイナリへのエントリポイントとして機能します(fn main() {}が含まれている必要があります)。あなたの例では、これは_src/bin/curl.rs_になります。

すべての「ライブラリ」コードは_src/lib.rs_(および追加のモジュール)に入ります。

最後に、バイナリの検索場所を説明するセクションを_Cargo.toml_に追加します。

_[[bin]]
name = "curl"
_

したがって、プロジェクトのレイアウトは次のようになります(_cargoを使用してプロジェクトに_curl-rs_という名前を付けたと仮定):

_$ tree curl-rs
curl-rs
├── bin
│   └── curl.rs
├── Cargo.toml
└── src
    └── lib.rs

2 directories, 3 files
_

_lib.rs_で定義されている機能を使用するには、外部depを使用する場合と同じです。

_// in src/bin/curl.rs
extern crate curl;

fn main() {
    // Do stuff
}
_

このプロジェクトをコンパイルすると、静的にリンクされたバイナリcurlが_target/{debug,release}_だけでなく_libcurl.rlib_にも配置されます。

5
kbknapp