logo标签列表

Cargo的build命令和rustc命令有什么区别？

rustrust-cargo
14

我是Rust的新手，我刚通过cargo new my_project创建了一个新项目。我注意到cargo提供了以下两个命令行选项：

  • build：编译本地包及其所有依赖项
  • rustc：编译一个包及其所有依赖项

我了解到后者可以用于编译我的机器上的任何项目，而前者只能在当前工作目录中使用。这是正确的吗？还有其他区别吗？在没有其他参数的情况下运行这两个命令将给出完全相同的输出。

Cargo通常没有rustc命令。您安装了Cargo扩展吗？ - nnnmmm
我只安装了 cargo-edit。 - Paul Razvan Berg
1
我错了，有一个 cargo rustc 命令，但它只会在 cargo --list 中显示，而不是 cargo --help。 - nnnmmm
3个回答
14

区别

为了全面了解这些命令在高层次上的差异，我们可以比较命令的实现。因此，我们首先会克隆cargo repo 

git clone https://github.com/rust-lang/cargo.git

然后将cargo build和cargo rustc的实现进行比较

diff -u -w cargo/src/bin/cargo/commands/build.rs cargo/src/bin/cargo/commands/rustc.rs

由此可以看出，cargo build和cargo rustc都是对内部cargo函数this的简单封装。

pub fn compile<'a>(ws: &Workspace<'a>, options: &CompileOptions) -> CargoResult<Compilation<'a>> {
    // ...
}

但是在暴露哪种选项方面存在差异。实际上，可以在cargo_compile.rs的顶部读到定义该函数的注释：

//! This module contains the entry point for starting the compilation process
//! for commands like `build`, `test`, `doc`, `rustc`, etc.

换句话说，cargo build 和 cargo rustc 不是唯一的紧密包装组合编译入口。

为什么要有不同的命令？

那么，为什么 cargo 的开发者要这样做呢？为什么不用一个单一的 cargo compile 命令，里面有很多标志，完全暴露底层实现呢？

显然，这肯定是为了以一种易于文档化和理解的方式来组织 Rust 生态系统中各个目标受众的事情。

Rust 生态系统的大部分新手不会想要接触调整编译器标志的可能性，因此在开始时只向他们公开 cargo build 及其特定风格的编译选项，并提供相应的文档，这是有道理的。

一旦他们成为更高级的用户，就会发现他们可以通过 cargo rustc 获得更详细的编译过程控制。

6

在工作目录方面没有区别。不同之处在于您可以如何将编译器选项传递给rustc，其中许多选项Cargo不知道/不公开：

cargo build [OPTIONS]：如果您想向rustc传递标志，通常无法在命令行上执行此操作，您需要使用RUSTFLAGS变量或编辑配置文件。

cargo rustc [OPTIONS] [-- ARGS]：可用的OPTIONS与cargo build大致相同，但args传递给rustc。因此，您可以编写cargo rustc --release -- -C overflow-checks=yes。

1
这个答案没有解释为什么我们需要这两个命令。正如所述，cargo build只是cargo rustc的一个不那么强大的版本，并且所有与cargo build一起工作的内容都可以使用cargo rustc来处理。 - mcarton
0
1
但是为什么要创建一个全新的命令，而不是将新参数添加到 cargo build、test 和 run 命令中呢？ - mcarton
我不确定，但我认为cargo rustc与rustc本身具有相同的参数，但cargo build无法添加其中一些参数，因为它们与旧键重叠。如果更改了build参数的含义，这将导致破坏，这是不好的。据我所知，cargo build比cargo rustc更早出现。 - Angelicos Phosphoros
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接