ad3dbe10e1
Add named config profiles.
This adds support for named config profiles. Previously, only `dev` and `release` were allowed in config files, it now supports all profile names. I think it would be strange to have arbitrarily named profiles in `Cargo.toml`, but not allow them in config. This is a deviation from the RFC, but RFC 2282 was written before named profiles which I think changes the landscape.
This diff is a little large due to some refactoring to make it work well. Overview of the changes:
- Removed `ProfileKind` and only use an `InternedString` to track the name of the profile. I didn't feel like the enum carried its cognitive weight, and it seems to simplify some things.
- `Profiles` is no longer stored in the manifest. There was no need to do a bunch of processing for each manifest. `Manifest` now only retains the low-level `TomlProfiles`. A single `Profiles` now lives in `BuildContext`.
- The profile name requested by the user is no longer passed around. It is given to `Profiles::new` and retained inside `Profiles`.
- `Profiles::get_profile` no longer follows the priority stack and inheritance each time a profile is requested. Instead, the profile is computed once (in `Profile::new`) and merged into a single profile. This simplifies getting a profile, and makes it easier to deal with getting the config values in one place.
- I switched profile names to be `InternedString` instead of `String`. There's not a strong reason to do this, other than it seemed a little strange to be creating lots of `String`s.
- I also added `PartialEq<str>` for `InternedString`. It has come up a few times in the past, and it seems useful. I'm not sure if it was excluded intentionally?
- The validation that the profile exists is now done in one place (`Profiles::new`).
- I removed the back-compatibility for the `overrides` key (which was renamed to `package` back in October).
Notes:
- Some of the error messages aren't as good as before, because they don't tell you where the error is located (`Cargo.toml` or `.cargo/config`). This is because the location data is lost by the time validation is done. Hopefully it will be obvious from the profile name and error message. I tried to improve error messages wherever I could.
- There are more calls to `clone()` than I would like, but they are kinda hard to avoid. Should be fewer than before.
- I noticed a bug with `-Zpanic-abort-tests` not supporting named profiles. I'll fix that separately.
- I think this fixes some bugs where package overrides in config weren't merging properly with package overrides defined in `Cargo.toml`.
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.