Skip to content

Commit

Permalink
Merge pull request #2373 from rust-lang/gh2287
Browse files Browse the repository at this point in the history
Clarify some package/crate distinctions in chapter 14
  • Loading branch information
steveklabnik committed Jun 14, 2020
2 parents c15f1bc + 833e663 commit 84ee234
Showing 1 changed file with 20 additions and 18 deletions.
38 changes: 20 additions & 18 deletions src/ch14-03-cargo-workspaces.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,8 @@ Next, in the *add* directory, we create the *Cargo.toml* file that will
configure the entire workspace. This file won’t have a `[package]` section or
the metadata we’ve seen in other *Cargo.toml* files. Instead, it will start
with a `[workspace]` section that will allow us to add members to the workspace
by specifying the path to our binary crate; in this case, that path is *adder*:
by specifying the path to the package with our binary crate; in this case,
that path is *adder*:

<span class="filename">Filename: Cargo.toml</span>

Expand Down Expand Up @@ -65,7 +66,7 @@ in your *add* directory should look like this:
```

The workspace has one *target* directory at the top level for the compiled
artifacts to be placed into; the `adder` crate doesn’t have its own *target*
artifacts to be placed into; the `adder` package doesn’t have its own *target*
directory. Even if we were to run `cargo build` from inside the *adder*
directory, the compiled artifacts would still end up in *add/target* rather
than *add/adder/target*. Cargo structures the *target* directory in a workspace
Expand All @@ -75,9 +76,9 @@ recompile each of the other crates in the workspace to have the artifacts in
its own *target* directory. By sharing one *target* directory, the crates can
avoid unnecessary rebuilding.

### Creating the Second Crate in the Workspace
### Creating the Second Package in the Workspace

Next, let’s create another member crate in the workspace and call it `add-one`.
Next, let’s create another member package in the workspace and call it `add-one`.
Change the top-level *Cargo.toml* to specify the *add-one* path in the
`members` list:

Expand Down Expand Up @@ -125,9 +126,10 @@ In the *add-one/src/lib.rs* file, let’s add an `add_one` function:
{{#rustdoc_include ../listings/ch14-more-about-cargo/no-listing-02-workspace-with-two-crates/add/add-one/src/lib.rs}}
```

Now that we have a library crate in the workspace, we can have the binary crate
`adder` depend on the library crate `add-one`. First, we’ll need to add a path
dependency on `add-one` to *adder/Cargo.toml*.
Now that we have another package in the workspace, we can have the `adder`
package with our binary depend on the `add-one` package, that has our
library. First, we’ll need to add a path dependency on `add-one` to
*adder/Cargo.toml*.

<span class="filename">Filename: adder/Cargo.toml</span>

Expand All @@ -149,8 +151,8 @@ function to call the `add_one` function, as in Listing 14-7.
{{#rustdoc_include ../listings/ch14-more-about-cargo/listing-14-07/add/adder/src/main.rs}}
```

<span class="caption">Listing 14-7: Using the `add-one` library crate from the
`adder` crate</span>
<span class="caption">Listing 14-7: Using the `add-one` library crate from the
`adder` crate</span>

Let’s build the workspace by running `cargo build` in the top-level *add*
directory!
Expand Down Expand Up @@ -187,12 +189,12 @@ Hello, world! 10 plus one is 11!

This runs the code in *adder/src/main.rs*, which depends on the `add-one` crate.

#### Depending on an External Crate in a Workspace
#### Depending on an External Package in a Workspace

Notice that the workspace has only one *Cargo.lock* file at the top level of
the workspace rather than having a *Cargo.lock* in each crate’s directory. This
ensures that all crates are using the same version of all dependencies. If we
add the `rand` crate to the *adder/Cargo.toml* and *add-one/Cargo.toml*
add the `rand` package to the *adder/Cargo.toml* and *add-one/Cargo.toml*
files, Cargo will resolve both of those to one version of `rand` and record
that in the one *Cargo.lock*. Making all crates in the workspace use the same
dependencies means the crates in the workspace will always be compatible with
Expand Down Expand Up @@ -237,7 +239,7 @@ The top-level *Cargo.lock* now contains information about the dependency of
`add-one` on `rand`. However, even though `rand` is used somewhere in the
workspace, we can’t use it in other crates in the workspace unless we add
`rand` to their *Cargo.toml* files as well. For example, if we add `use rand;`
to the *adder/src/main.rs* file for the `adder` crate, we’ll get an error:
to the *adder/src/main.rs* file for the `adder` package, we’ll get an error:

<!-- manual-regeneration
cd listings/ch14-more-about-cargo/output-only-03-use-rand/add
Expand All @@ -256,14 +258,14 @@ error[E0432]: unresolved import `rand`
| ^^^^ no `rand` external crate
```

To fix this, edit the *Cargo.toml* file for the `adder` crate and indicate that
`rand` is a dependency for that crate as well. Building the `adder` crate will
To fix this, edit the *Cargo.toml* file for the `adder` package and indicate
that `rand` is a dependency for it as well. Building the `adder` package will
add `rand` to the list of dependencies for `adder` in *Cargo.lock*, but no
additional copies of `rand` will be downloaded. Cargo has ensured that every
crate in the workspace using the `rand` crate will be using the same version.
Using the same version of `rand` across the workspace saves space because we
won’t have multiple copies and ensures that the crates in the workspace will be
compatible with each other.
crate in every package in the workspace using the `rand` package will be
using the same version. Using the same version of `rand` across the workspace
saves space because we won’t have multiple copies and ensures that the crates
in the workspace will be compatible with each other.

#### Adding a Test to a Workspace

Expand Down

0 comments on commit 84ee234

Please sign in to comment.