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

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

如果在代码中几乎所有地方都使用外部板条箱（E）（即我的本地lib板条箱和二进制板条箱），那么必须在所有

Cargo.toml

依赖项中包含E

问题:

• 这是否意味着E的代码在最终的二进制文件中包含多次
• 如果我想更新E的版本，我必须更改所有

  Cargo.toml

  文件。是否有其他方法可以指定“公共”依赖项
• 所引用的方法是惯用的吗？虽然可能，但锈菌社区似乎不提倡在工作区内安装1个子板条箱

我知道使用动态库在某种程度上是一种解决方案；但是，我的项目是一个嵌入式项目，不支持动态库

这是我个人的印象；对不起，如果我错了

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

你没有解释你为什么要这样做。如果出于编译性能的原因，那么您可能只想等待更好的增量编译支持。根据所涉及的代码类型，拆分成板条箱可能有助于缩短编译时间，也可能没有帮助——例如，具有高度通用API的板条箱的好处会更少

我认为语义/组织上的原因是分裂事物的最佳理由

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

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

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

您的Cargo.toml文件不需要更改，除非您需要升级到一个semver不兼容的板条箱版本。您的Cargo.lock，这是唯一需要更改的文件

所引用的方法是惯用的吗？虽然可能，但锈菌社区似乎不提倡在工作区内的板条箱旁边放置子板条箱

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