dc4b695f41
This commit updates Cargo's build of host dependencies to build them
with optimization level 0 by default instead of matching the profile of
the final binary.
Since Cargo's inception build dependencies have, by default, been built
in a profile that largely matches the profile of the final target
artifact. Build dependencies, however, rarely actually need to be
optimized and are often executing very small tasks, which means that
optimizing them often wastes a lot of build time. A great example of
this is procedural macros where `syn` and friends are pretty heavyweight
to optimize, and the amount of Rust code they're parsing is typically
quite small, so the time spent optimizing rarely comes as a benefit.
The goal of this PR is to improve build times on average in the
community by not spending time optimizing build dependencies (build
scripts, procedural macros, and their transitive dependencies). The PR
will not be a universal win for everyone, however. There's some
situations where your build time may actually increase:
* In some cases build scripts and procedural macros can take quite a
long time to run!
* Cargo may not build dependencies more than once if they're shared with
the main build. This only applies to builds without `--target` where
the same crate is used in the final binary as in a build script.
In these cases, however, the `build-override` profile has existed for
some time know and allows giving a knob to tweak this behavior. For
example to get back the previous build behavior of Cargo you would
specify, in `Cargo.toml`:
[profile.release.build-override]
opt-level = 3
or you can configure this via the environment:
export CARGO_PROFILE_RELEASE_BUILD_OVERRIDE_OPT_LEVEL=3
There are two notable features we would like to add in the future which
would make the impact of a change like this smaller, but they're not
implemented at this time (nor do we have concrete plans to implement
them). First we would like crates to have a way of specifying they
should be optimized by default, despite default profile options. Often
crates, like lalrpop historically, have abysmal performance in debug
mode and almost always (even in debug builds) want to be built in
release mode. The second feature is that ideally crate authors would be
able to tell Cargo to minimize the number of crates built, unifying
profiles where possible to avoid double-compiling crates.
At this time though the Cargo team feels that the benefit of changing
the defaults is well worth this change. Neither today nor directly after
this change will be a perfect world, but it's hoped that this change
makes things less bad!
Cargo
Cargo downloads your Rust project’s dependencies and compiles your project.
Learn more at https://doc.rust-lang.org/cargo/
Code Status
Code documentation: https://docs.rs/cargo/
Installing Cargo
Cargo is distributed by default with Rust, so if you've got rustc installed
locally you probably also have cargo installed locally.
Compiling from Source
Cargo requires the following tools and packages to build:
gitcurl(on Unix)pkg-config(on Unix, used to figure out thelibsslheaders/libraries)- OpenSSL headers (only for Unix, this is the
libssl-devpackage on ubuntu) cargoandrustc
First, you'll want to check out this repository
git clone https://github.com/rust-lang/cargo
cd cargo
With cargo already installed, you can simply run:
cargo build --release
Adding new subcommands to Cargo
Cargo is designed to be extensible with new subcommands without having to modify Cargo itself. See the Wiki page for more details and a list of known community-developed subcommands.
Releases
Cargo releases coincide with Rust releases. High level release notes are available as part of Rust's release notes. Detailed release notes are available in this repo at CHANGELOG.md.
Reporting issues
Found a bug? We'd love to know about it!
Please report all issues on the GitHub issue tracker.
Contributing
See CONTRIBUTING.md. You may also find the architecture documentation useful (ARCHITECTURE.md).
License
Cargo is primarily distributed under the terms of both the MIT license and the Apache License (Version 2.0).
See LICENSE-APACHE and LICENSE-MIT for details.
Third party software
This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit (https://www.openssl.org/).
In binary form, this product includes software that is licensed under the terms of the GNU General Public License, version 2, with a linking exception, which can be obtained from the upstream repository.
See LICENSE-THIRD-PARTY for details.