15

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

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

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

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

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

4

2 回答 2

24

cargo install

从Rust 1.5开始，您可以使用cargo install将二进制 crate安装到您的系统上。您可以从以下位置安装板条箱：

  • 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可用于移除之前安装的 crate。如果您安装了多个同名的 crate，您可以指定--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
于 2016-01-08T04:49:00.157 回答
4

（此答案适用于想要分发自己的程序的开发人员，而不是已收到 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。这将在 中放置一个（主要是，请参阅下面的缺点）静态链接的 crate 二进制文件target/release/crate_name，并且可以将其重新打包成.tar.gzor.zip并分发给其他用户。

优点：

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

缺点：

  • 安装.tar.gz/.zip是非标准的，对于大多数用户来说通常不被认为是理想的。
  • 如果 crate 需要任何系统依赖项超出libc，它将无法加载它们并出现难以理解的错误。
  • 这需要开发人员为每个版本和平台组合手动构建要发布的包。

使用 CI 服务构建发布

可以使用基于云的 CI 服务重新创建任何这些方法。例如，使用Travis CI，您可以使用Trust项目以与 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

于 2020-12-02T21:25:51.037 回答