外部库作为对本地库的依赖

Question

在像C这样的语言中，我们处理三种不同的翻译单元：目标文件，库和可执行文件。如果我已经理解正确，Rust已经跳过了第一个。也就是说，如果我想将我的项目分成几个翻译单元，我必须使用本地包，如blog所示。

如果在代码中几乎所有地方使用extern crate（E）（即我的本地lib crates和二进制包），那么必须在所有Cargo.toml依赖项中包含E.

问题：

• 这是否意味着在最终二进制文件中多次包含E代码？
• 如果我想更新E的版本，我必须更改所有Cargo.toml个文件。有没有其他我可以指定＆＃34;普通＆＃34;依赖性？
• 引用的方法是否惯用？虽然可能，Rust社区似乎不提倡工作区旁边的 ¹ 子板条

我知道使用动态库部分是解决方案;但是，我的项目是一个不支持动态库的嵌入式项目。

¹ 这是我的个人印象;对不起，如果我在这里错了。

Answer 1

  

我想将我的项目分成几个翻译单元

您没有解释为什么您想要这样做。如果是出于编译性能的原因，那么您可能只想等待更好的增量编译支持。根据所涉及的代码类型，分割成包装箱可能会或可能没有帮助编译时间 - 例如，具有高度通用API的包装箱将获得较少的好处。

我会说语义/组织原因是分解的最佳理由。

  

这是否意味着E的代码在最终二进制文件中被多次包含？

没有。当Cargo执行依赖项解析时，它会尝试解析每个依赖项的单个版本。如果您的依赖关系树具有冲突的版本要求，那么可能会包含多个版本，但这是编译此类代码的唯一方法。使用像货物树这样的工具可以帮助您找到强制包含多个版本的板条箱。

  

我必须更改所有Cargo.toml文件。

您的 Cargo.toml 文件不需要更改，除非您需要升级到crate的semver不兼容版本。您的 Cargo.lock ，only exists for your final binary是唯一需要更改的文件。

  

引用的方法是否惯用？虽然可能，Rust社区似乎不提倡工作区旁边的子板条

我看到的主要缺点是，如果你想做那样的话，你需要发布多个板条箱。如果您只是构建二进制文件，我认为没有理由不这样做。 Parity是一个更大的二进制项目的示例，它由许多较小的包装箱组成。