Cargo.lockto decide which dependencies to download and build.
cargo updateis effectively equivalent to removing
Cargo.lockand then running
cargo buildif there wasn't a
cargo cleanin-between. It updates
Cargo.lockwith more recent compatible versions of packages in the repo.
cargofeatures are supposed to be additive. This has been known to break
Cargo.toml. See here for more information about what a compatible version means. I.e. if not using
cargowill check if a newer version exists (both on disk and from the repo) before deciding what version of a crate to (possibly download and) build.
cargoworks on a DAG, crates whose deps were updated as a result of
cargo update(which can happen if their
Cargo.tomls use caret versioning) will be rebuilt as well.
cargowill use the most up-to-date version from the repository.
cargowill use the existing crate version on-disk already to satisfy the wildcard, even if its a less recent version.
Cargo.lockwhen I observed this behavior? See CargoDump.
cargodoesn't download/build crates if it doesn't have to. This can be demonstrated by taking a repo with dependencies still intact, making a copy of
cargo build, and then replacing the updated
Cargo.lockwith the old one.
cargowill simply hard link the binary under
targetto the existing old binary to "build" it.
Last Updated: 2019-10-30