ローカルライブラリへの依存としてのExternライブラリ

Question

Cのような言語では、オブジェクトファイル、ライブラリ、および実行可能ファイルの3つの異なる翻訳単位を扱います。私が正しく理解していれば、Rustは最初をスキップしました。つまり、プロジェクトを複数の翻訳単位に分割したい場合は、このblogに示すようにローカルの箱を使用する必要があります。

コード内にextern crate（E）を使用すると、すべてのCargo.tomlの依存関係にEを含める必要があります（つまり、自分のローカルlibboxとバイナリクレート）。

質問：

• これはEのコードが最終的なバイナリに数回含まれていることを意味していますか？
• Eのバージョンを更新したい場合は、すべてCargo.tomlファイルを変更する必要があります。 「共通」の依存関係を指定できる代替方法はありますか？
• 引用したアプローチは慣用的ですか？可能ではあるが、錆のコミュニティは、私は動的ライブラリを使用すると、一部では解決策になることを承知しているワークスペース

での横にサブクレートを提唱していないようです。しかし、私のプロジェクトは、動的ライブラリをサポートしない埋め込み型のプロジェクトです。

これは私の個人的な印象です。私がここで間違っていると申し訳ありません。

Answer 1

私はは、あなたがこれをしたい理由をを説明していないいくつかの翻訳単位

に私のプロジェクトを分割したいです。コンパイルのパフォーマンス上の理由から、より良いインクリメンタル・コンパイル・サポートが必要な場合があります。クレートへの分割は、どのような種類のコードが含まれているかに基づいてコンパイル時間に役立つかもしれませんし、役立たないかもしれません。

私は意味論的/組織的な理由が物事を分割する最善の理由だと思います。

これは、Eのコードが最後のバイナリに複数回含まれていることを意味しますか？

No. Cargoは依存関係の解決を実行するときに、各依存関係の単一バージョンの解決を試みます。依存関係ツリーにバージョンの要件が矛盾している場合は、複数のバージョンが含まれていてもかまいませんが、これはそのようなコードをコンパイルする唯一の方法です。カーゴツリーのようなツールを使用すると、複数のバージョンを強制的に含むクレートを見つけることができます。

すべてのCargo.tomlファイルを変更する必要があります。あなたはクレートのsemver互換性のないバージョンにアップグレードする必要がありない限り

あなたCargo.tomlファイルを変更する必要はありません。 Cargo.lock、only exists for your final binaryは変更が必要な唯一のファイルです。

引用したアプローチは慣用的ですか？可能ではあるが、錆のコミュニティは、ワークスペース

での横にサブクレートを提唱していないようで、私が見る主な欠点は、あなたがそのようなことをやってみたかった場合複数の箱を公開にする必要がありますということです。バイナリを構築しているだけの場合は、そうしない理由はありません。 Parityは、多くの小さなクレートで構成されるより大きなバイナリプロジェクトの例です。