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

Question

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

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

Cargo本身使用额外的configure/make来处理配置,检测系统依赖性,运行cargo build和安装.

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

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

Answer 1

cargo install

从Rust 1.5开始,您可以使用在系统上cargo install安装二进制包.您可以从以下位置安装包装箱:

• crates.io(默认值),使用 cargo install crate_name
• 任何git存储库,使用 cargo install --git repository_url
• 任何目录,使用 cargo install --path /path/to/crate

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

• 使用crates.io,您可以使用--vers指定crate版本.
• 使用git存储库,您可以使用--branch设置要安装的分支,--tag指定要使用的标记版本,以及--rev从特定提交构建.

安装地点:

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

• 通过--root /path/to/directory(这条路可以是相对的)
• 通过设置$CARGO_INSTALL_ROOT环境变量
• 通过设置install.root 配置键
• 通过设置$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 答案的领域）。

除了托比的回答：

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

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

换句话说，cargo install就是make && sudo make installCargo 程序的；这不是分发 Rust 程序的理想方式，除非它主要面向 Rust 程序员。

那么正确的方法是什么呢？

让我们看看替代方案。

手动分发 tarball/zip

cargo install您只需使用 即可复制效果cargo build --release。这将在 中放置一个（主要是，请参见下面的缺点）静态链接的板条箱二进制文件target/release/crate_name，并且可以将其重新打包到.tar.gzor中.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 安装程序包。

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

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