配置/安装使用Rust Cargo作为构建系统的软件的预期/计划方式是什么？

Question

现有的构建系统通常具有某种安装目标，可以手动（用于安装在/ usr / local或用户可以访问的其他位置）或自动（通过基于二进制的发行版的包构建系统或包管理器）使用基于源的）。

安装使用Cargo的软件的预期方式是什么？ make install的类似物应该是什么样的？

Cargo本身使用额外的配置/制作来处理配置，检测系统依赖性，运行cargo build和安装。

对于使用Cargo构建的任何其他软件，这是否正确？这意味着是否有计划通过Cargo本身来完成这项任务，或者Cargo是否只是作为依赖程序获取和编译的工具而没有任何配置/检测已安装的deps /安装？

或者是否有计划添加此功能？

Answer 1

cargo install

从Rust 1.5开始，您可以使用cargo install将binary crates安装到您的系统上。您可以从以下位置安装包装箱：

• crates.io（默认值），使用cargo install crate_name
• 任何git存储库，使用cargo install --git repository_url
• 使用cargo install --path /path/to/crate
的任何目录

前两个可以指定其他选项：

• 使用crates.io，您可以使用--vers指定包装箱版本。
• 使用git存储库，您可以使用--branch设置要从中安装的分支，--tag以指定要使用的标记版本，并--rev从特定提交构建。< / LI>

安装位置：

可以将

cargo install配置为按优先顺序（最高优先级）通过以下方法安装在自定义目录中：

• 传递--root /path/to/directory（此路径可以是相对的）
• 通过设置$CARGO_INSTALL_ROOT环境变量
• 设置install.root configuration key
• 设置$CARGO_HOME环境变量（会影响cargo install以上的安装目录）

如果上述情况均不存在，货物将在~/.cargo/bin安装包装箱。

在上述所有情况下，输出文件实际上都会放在bin子目录中（例如--root /path/to/directory实际上会将输出放在/path/to/directory/bin）。

卸载

cargo uninstall可用于删除以前安装的包装箱。如果您安装了多个具有相同名称的包，则可以指定--root以仅删除该目录中的版本。

示例：我想使用rustfmt：

我可以在crates.io上使用该版本：

• cargo install rustfmt

我喜欢使用原始版本：

• cargo install rustfmt --vers 0.0.1

我希望它安装在/opt/rust_crates：

中

• cargo install rustfmt --root /opt/rust_crates

我真的需要使用最前沿的版本：

• cargo install --git https://github.com/rust-lang-nursery/rustfmt.git

最新的提交有一个错误！

• cargo install --git https://github.com/rust-lang-nursery/rustfmt.git --rev f5bd7b76e0185e8dd37ae6b1b5fb5e11187f0b8c

我真的希望使用git子模块作为其依赖项的版本：

• cargo install --git https://github.com/rust-lang-nursery/rustfmt.git --branch submods

我克隆了它并做了一些修改：

• cargo install --path ~/my_rustfmt

实际上，我坚持完全手动完成格式化：

• cargo uninstall rustfmt

Answer 2

（此答案适用于希望分发自己的程序的开发人员，而不是已收到Cargo项目并需要在自己的系统上安装它的用户；这是Toby的答案的域。）

除了Toby's Answer：

Cargo的安装功能并不是发行Rust程序的主要方式。它仅设计用于分发给其他Rust开发人员。使用此功能有几个缺点：

• 货物要求最终用户首先安装整个Rust工具链。
• 用户将不得不在本地构建程序，这可能会很慢，尤其是在Rust中。
• 安装程序后（不安装additional tool）不支持升级程序。
• （当前）无法包含资产，例如文档。
• 除非将标志传递给cargo install，否则软件包将仅为当前用户安装。

换句话说，cargo install是货运程序的make && sudo make install；除非主要用于Rust程序员，否则它不是分发Rust程序的理想方法。

那正确的方法是什么？

让我们看看替代方案。

手动分发tarball / zip

您只需使用cargo install就可以复制cargo build --release的效果。这将在target/release/crate_name中放置一个（通常会看到以下缺点的）静态链接的板条箱二进制文件，并且可以将其重新包装为.tar.gz或.zip并分发给其他用户。

优点：

• 不需要用户安装Rust或自己构建程序。
• 允许开发人员将资产复制到tarball / zip文件中，并将其与程序本身一起分发。

缺点：

• 安装.tar.gz / .zip是非标准的，通常对于大多数用户而言并不理想。
• 如果板条箱需要libc以外的任何系统依赖项，则将无法加载它们，并带来难以理解的错误。
• 这需要开发人员手动构建一个软件包以针对每个版本和平台组合发布。

使用CI服务构建发行版

使用基于云的CI服务可以重新创建任何这些方法。例如，使用Travis CI，您可以使用Trust项目以与从tarball大致相同的方式自动进行部署，但只需标签就可以自动进行部署。

优点：

（加上tarball的所有优点）

• 开发人员不必手动发布程序，只需标记发布。
• 作为副作用，可以为程序一次支持的每个程序包构建。

缺点：

• 如果无法正常运行，则调试过程可能会令人沮丧，因为对服务器的控制有限。
• 构建过程与服务相关，这意味着如果服务在发布时关闭，则发布可能会丢失。
• 使用Trust或类似工具，您最终仍将分发.tar.gz / .zip，这意味着仍然给用户带来不便，并且缺乏系统依赖性管理。

除了Travis之外，请参阅Appveyor和GitHub Actions作为可能的构建平台。

提供一个软件包

这被认为是许多最终用户的理想方法，并且是分发任何程序（不仅仅是Cargo程序）的标准方法。这缓解了tarball方法的几乎所有问题，尽管并非没有其自身的一些问题。

优点：

• 与其他任何程序一样包含在系统中。
• 可以提交到Linux发行版本信息库，以仅用一个命令即可安装程序。
• 允许更新，删除和包含资产。
• 跟踪系统依赖性，这对GUI应用程序特别有用。

缺点：

• 到目前为止，这些选项中最复杂的。
• 需要为每个受支持的平台分别构建一个程序包（可以通过CI来缓解，但是用这种方式设置会更加复杂。）

最好使用其他工具来处理这种方法：

• cargo-deb：为Debian和Ubuntu构建一个软件包。
• cargo-rpm：为Fedora，Red Hat和CentOS构建一个软件包。
• cargo-aur：为Arch Linux构建软件包。
• cargo-wix：制作一个Windows Installer程序包。

这些通常是开发人员要运行的工具，用于创建用于生成软件包的文件。有关更多信息，请参阅他们自己的文档。

来源：https://rust-cli.github.io/book/tutorial/packaging.html