src/tools/cargo/src/doc/src/reference/manifest.md

   1 # The Manifest Format
   2
   3 The `Cargo.toml` file for each package is called its *manifest*. It is written
   4 in the [TOML] format. It contains metadata that is needed to compile the package. Checkout
   5 the `cargo locate-project` section for more detail on how cargo finds the manifest file.
   6
   7 Every manifest file consists of the following sections:
   8
   9 * [`cargo-features`](unstable.md) --- Unstable, nightly-only features.
  10 * [`[package]`](#the-package-section) --- Defines a package.
  11   * [`name`](#the-name-field) --- The name of the package.
  12   * [`version`](#the-version-field) --- The version of the package.
  13   * [`authors`](#the-authors-field) --- The authors of the package.
  14   * [`edition`](#the-edition-field) --- The Rust edition.
  15   * [`rust-version`](#the-rust-version-field) --- The minimal supported Rust version.
  16   * [`description`](#the-description-field) --- A description of the package.
  17   * [`documentation`](#the-documentation-field) --- URL of the package documentation.
  18   * [`readme`](#the-readme-field) --- Path to the package's README file.
  19   * [`homepage`](#the-homepage-field) --- URL of the package homepage.
  20   * [`repository`](#the-repository-field) --- URL of the package source repository.
  21   * [`license`](#the-license-and-license-file-fields) --- The package license.
  22   * [`license-file`](#the-license-and-license-file-fields) --- Path to the text of the license.
  23   * [`keywords`](#the-keywords-field) --- Keywords for the package.
  24   * [`categories`](#the-categories-field) --- Categories of the package.
  25   * [`workspace`](#the-workspace-field) --- Path to the workspace for the package.
  26   * [`build`](#the-build-field) --- Path to the package build script.
  27   * [`links`](#the-links-field) --- Name of the native library the package links with.
  28   * [`exclude`](#the-exclude-and-include-fields) --- Files to exclude when publishing.
  29   * [`include`](#the-exclude-and-include-fields) --- Files to include when publishing.
  30   * [`publish`](#the-publish-field) --- Can be used to prevent publishing the package.
  31   * [`metadata`](#the-metadata-table) --- Extra settings for external tools.
  32   * [`default-run`](#the-default-run-field) --- The default binary to run by [`cargo run`].
  33   * [`autobins`](cargo-targets.md#target-auto-discovery) --- Disables binary auto discovery.
  34   * [`autoexamples`](cargo-targets.md#target-auto-discovery) --- Disables example auto discovery.
  35   * [`autotests`](cargo-targets.md#target-auto-discovery) --- Disables test auto discovery.
  36   * [`autobenches`](cargo-targets.md#target-auto-discovery) --- Disables bench auto discovery.
  37   * [`resolver`](resolver.md#resolver-versions) --- Sets the dependency resolver to use.
  38 * Target tables: (see [configuration](cargo-targets.md#configuring-a-target) for settings)
  39   * [`[lib]`](cargo-targets.md#library) --- Library target settings.
  40   * [`[[bin]]`](cargo-targets.md#binaries) --- Binary target settings.
  41   * [`[[example]]`](cargo-targets.md#examples) --- Example target settings.
  42   * [`[[test]]`](cargo-targets.md#tests) --- Test target settings.
  43   * [`[[bench]]`](cargo-targets.md#benchmarks) --- Benchmark target settings.
  44 * Dependency tables:
  45   * [`[dependencies]`](specifying-dependencies.md) --- Package library dependencies.
  46   * [`[dev-dependencies]`](specifying-dependencies.md#development-dependencies) --- Dependencies for examples, tests, and benchmarks.
  47   * [`[build-dependencies]`](specifying-dependencies.md#build-dependencies) --- Dependencies for build scripts.
  48   * [`[target]`](specifying-dependencies.md#platform-specific-dependencies) --- Platform-specific dependencies.
  49 * [`[badges]`](#the-badges-section) --- Badges to display on a registry.
  50 * [`[features]`](features.md) --- Conditional compilation features.
  51 * [`[lints]`](#the-lints-section) --- Configure linters for this package.
  52 * [`[patch]`](overriding-dependencies.md#the-patch-section) --- Override dependencies.
  53 * [`[replace]`](overriding-dependencies.md#the-replace-section) --- Override dependencies (deprecated).
  54 * [`[profile]`](profiles.md) --- Compiler settings and optimizations.
  55 * [`[workspace]`](workspaces.md) --- The workspace definition.
  56
  57 ## The `[package]` section
  58
  59 The first section in a `Cargo.toml` is `[package]`.
  60
  61 ```toml
  62 [package]
  63 name = "hello_world" # the name of the package
  64 version = "0.1.0"    # the current version, obeying semver
  65 authors = ["Alice <a@example.com>", "Bob <b@example.com>"]
  66 ```
  67
  68 The only fields required by Cargo are [`name`](#the-name-field) and
  69 [`version`](#the-version-field). If publishing to a registry, the registry may
  70 require additional fields. See the notes below and [the publishing
  71 chapter][publishing] for requirements for publishing to [crates.io].
  72
  73 ### The `name` field
  74
  75 The package name is an identifier used to refer to the package. It is used
  76 when listed as a dependency in another package, and as the default name of
  77 inferred lib and bin targets.
  78
  79 The name must use only [alphanumeric] characters or `-` or `_`, and cannot be empty.
  80
  81 Note that [`cargo new`] and [`cargo init`] impose some additional restrictions on
  82 the package name, such as enforcing that it is a valid Rust identifier and not
  83 a keyword. [crates.io] imposes even more restrictions, such as:
  84
  85 - Only ASCII characters are allowed.
  86 - Do not use reserved names.
  87 - Do not use special Windows names such as "nul".
  88 - Use a maximum of 64 characters of length.
  89
  90 [alphanumeric]: ../../std/primitive.char.html#method.is_alphanumeric
  91
  92 ### The `version` field
  93
  94 Cargo bakes in the concept of [Semantic
  95 Versioning](https://semver.org/), so make sure you follow some basic rules:
  96
  97 * Before you reach 1.0.0, anything goes, but if you make breaking changes,
  98   increment the minor version. In Rust, breaking changes include adding fields to
  99   structs or variants to enums.
 100 * After 1.0.0, only make breaking changes when you increment the major version.
 101   Don’t break the build.
 102 * After 1.0.0, don’t add any new public API (no new `pub` anything) in patch-level
 103   versions. Always increment the minor version if you add any new `pub` structs,
 104   traits, fields, types, functions, methods or anything else.
 105 * Use version numbers with three numeric parts such as 1.0.0 rather than 1.0.
 106
 107 See the [Resolver] chapter for more information on how Cargo uses versions to
 108 resolve dependencies, and for guidelines on setting your own version. See the
 109 [SemVer compatibility] chapter for more details on exactly what constitutes a
 110 breaking change.
 111
 112 [Resolver]: resolver.md
 113 [SemVer compatibility]: semver.md
 114
 115 ### The `authors` field
 116
 117 The optional `authors` field lists in an array the people or organizations that are considered
 118 the "authors" of the package. The exact meaning is open to interpretation --- it
 119 may list the original or primary authors, current maintainers, or owners of the
 120 package. An optional email address may be included within angled brackets at
 121 the end of each author entry.
 122
 123 ```toml
 124 [package]
 125 # ...
 126 authors = ["Graydon Hoare", "Fnu Lnu <no-reply@rust-lang.org>"]
 127 ```
 128
 129 This field is only surfaced in package metadata and in the `CARGO_PKG_AUTHORS`
 130 environment variable within `build.rs`. It is not displayed in the [crates.io]
 131 user interface.
 132
 133 > **Warning**: Package manifests cannot be changed once published, so this
 134 > field cannot be changed or removed in already-published versions of a
 135 > package.
 136
 137 ### The `edition` field
 138
 139 The `edition` key is an optional key that affects which [Rust Edition] your package
 140 is compiled with. Setting the `edition` key in `[package]` will affect all
 141 targets/crates in the package, including test suites, benchmarks, binaries,
 142 examples, etc.
 143
 144 ```toml
 145 [package]
 146 # ...
 147 edition = '2021'
 148 ```
 149
 150 Most manifests have the `edition` field filled in automatically by [`cargo new`]
 151 with the latest stable edition. By default `cargo new` creates a manifest with
 152 the 2021 edition currently.
 153
 154 If the `edition` field is not present in `Cargo.toml`, then the 2015 edition is
 155 assumed for backwards compatibility. Note that all manifests
 156 created with [`cargo new`] will not use this historical fallback because they
 157 will have `edition` explicitly specified to a newer value.
 158
 159 ### The `rust-version` field
 160
 161 The `rust-version` field is an optional key that tells cargo what version of the
 162 Rust language and compiler your package can be compiled with. If the currently
 163 selected version of the Rust compiler is older than the stated version, cargo
 164 will exit with an error, telling the user what version is required.
 165
 166 The first version of Cargo that supports this field was released with Rust 1.56.0.
 167 In older releases, the field will be ignored, and Cargo will display a warning.
 168
 169 ```toml
 170 [package]
 171 # ...
 172 rust-version = "1.56"
 173 ```
 174
 175 The Rust version must be a bare version number with two or three components; it
 176 cannot include semver operators or pre-release identifiers. Compiler pre-release
 177 identifiers such as -nightly will be ignored while checking the Rust version.
 178 The `rust-version` must be equal to or newer than the version that first
 179 introduced the configured `edition`.
 180
 181 The `rust-version` may be ignored using the `--ignore-rust-version` option.
 182
 183 Setting the `rust-version` key in `[package]` will affect all targets/crates in
 184 the package, including test suites, benchmarks, binaries, examples, etc.
 185
 186 ### The `description` field
 187
 188 The description is a short blurb about the package. [crates.io] will display
 189 this with your package. This should be plain text (not Markdown).
 190
 191 ```toml
 192 [package]
 193 # ...
 194 description = "A short description of my package"
 195 ```
 196
 197 > **Note**: [crates.io] requires the `description` to be set.
 198
 199 ### The `documentation` field
 200
 201 The `documentation` field specifies a URL to a website hosting the crate's
 202 documentation. If no URL is specified in the manifest file, [crates.io] will
 203 automatically link your crate to the corresponding [docs.rs] page when the
 204 documentation has been built and is available (see [docs.rs queue]).
 205
 206 ```toml
 207 [package]
 208 # ...
 209 documentation = "https://docs.rs/bitflags"
 210 ```
 211
 212 [docs.rs queue]: https://docs.rs/releases/queue
 213
 214 ### The `readme` field
 215
 216 The `readme` field should be the path to a file in the package root (relative
 217 to this `Cargo.toml`) that contains general information about the package.
 218 This file will be transferred to the registry when you publish. [crates.io]
 219 will interpret it as Markdown and render it on the crate's page.
 220
 221 ```toml
 222 [package]
 223 # ...
 224 readme = "README.md"
 225 ```
 226
 227 If no value is specified for this field, and a file named `README.md`,
 228 `README.txt` or `README` exists in the package root, then the name of that
 229 file will be used. You can suppress this behavior by setting this field to
 230 `false`. If the field is set to `true`, a default value of `README.md` will
 231 be assumed.
 232
 233 ### The `homepage` field
 234
 235 The `homepage` field should be a URL to a site that is the home page for your
 236 package.
 237
 238 ```toml
 239 [package]
 240 # ...
 241 homepage = "https://serde.rs/"
 242 ```
 243
 244 ### The `repository` field
 245
 246 The `repository` field should be a URL to the source repository for your
 247 package.
 248
 249 ```toml
 250 [package]
 251 # ...
 252 repository = "https://github.com/rust-lang/cargo/"
 253 ```
 254
 255 ### The `license` and `license-file` fields
 256
 257 The `license` field contains the name of the software license that the package
 258 is released under. The `license-file` field contains the path to a file
 259 containing the text of the license (relative to this `Cargo.toml`).
 260
 261 [crates.io] interprets the `license` field as an [SPDX 2.1 license
 262 expression][spdx-2.1-license-expressions]. The name must be a known license
 263 from the [SPDX license list 3.11][spdx-license-list-3.11]. Parentheses are not
 264 currently supported. See the [SPDX site] for more information.
 265
 266 SPDX license expressions support AND and OR operators to combine multiple
 267 licenses.[^slash]
 268
 269 ```toml
 270 [package]
 271 # ...
 272 license = "MIT OR Apache-2.0"
 273 ```
 274
 275 Using `OR` indicates the user may choose either license. Using `AND` indicates
 276 the user must comply with both licenses simultaneously. The `WITH` operator
 277 indicates a license with a special exception. Some examples:
 278
 279 * `MIT OR Apache-2.0`
 280 * `LGPL-2.1-only AND MIT AND BSD-2-Clause`
 281 * `GPL-2.0-or-later WITH Bison-exception-2.2`
 282
 283 If a package is using a nonstandard license, then the `license-file` field may
 284 be specified in lieu of the `license` field.
 285
 286 ```toml
 287 [package]
 288 # ...
 289 license-file = "LICENSE.txt"
 290 ```
 291
 292 > **Note**: [crates.io] requires either `license` or `license-file` to be set.
 293
 294 [^slash]: Previously multiple licenses could be separated with a `/`, but that
 295 usage is deprecated.
 296
 297 ### The `keywords` field
 298
 299 The `keywords` field is an array of strings that describe this package. This
 300 can help when searching for the package on a registry, and you may choose any
 301 words that would help someone find this crate.
 302
 303 ```toml
 304 [package]
 305 # ...
 306 keywords = ["gamedev", "graphics"]
 307 ```
 308
 309 > **Note**: [crates.io] allows a maximum of 5 keywords. Each keyword must be
 310 > ASCII text, have at most 20 characters, start with an alphanumeric character,
 311 > and only contain letters, numbers, `_`, `-` or `+`.
 312
 313 ### The `categories` field
 314
 315 The `categories` field is an array of strings of the categories this package
 316 belongs to.
 317
 318 ```toml
 319 categories = ["command-line-utilities", "development-tools::cargo-plugins"]
 320 ```
 321
 322 > **Note**: [crates.io] has a maximum of 5 categories. Each category should
 323 > match one of the strings available at <https://crates.io/category_slugs>, and
 324 > must match exactly.
 325
 326 ### The `workspace` field
 327
 328 The `workspace` field can be used to configure the workspace that this package
 329 will be a member of. If not specified this will be inferred as the first
 330 Cargo.toml with `[workspace]` upwards in the filesystem. Setting this is
 331 useful if the member is not inside a subdirectory of the workspace root.
 332
 333 ```toml
 334 [package]
 335 # ...
 336 workspace = "path/to/workspace/root"
 337 ```
 338
 339 This field cannot be specified if the manifest already has a `[workspace]`
 340 table defined. That is, a crate cannot both be a root crate in a workspace
 341 (contain `[workspace]`) and also be a member crate of another workspace
 342 (contain `package.workspace`).
 343
 344 For more information, see the [workspaces chapter](workspaces.md).
 345
 346 ### The `build` field
 347
 348 The `build` field specifies a file in the package root which is a [build
 349 script] for building native code. More information can be found in the [build
 350 script guide][build script].
 351
 352 [build script]: build-scripts.md
 353
 354 ```toml
 355 [package]
 356 # ...
 357 build = "build.rs"
 358 ```
 359
 360 The default is `"build.rs"`, which loads the script from a file named
 361 `build.rs` in the root of the package. Use `build = "custom_build_name.rs"` to
 362 specify a path to a different file or `build = false` to disable automatic
 363 detection of the build script.
 364
 365 ### The `links` field
 366
 367 The `links` field specifies the name of a native library that is being linked
 368 to. More information can be found in the [`links`][links] section of the build
 369 script guide.
 370
 371 [links]: build-scripts.md#the-links-manifest-key
 372
 373 For example, a crate that links a native library called "git2" (e.g. `libgit2.a`
 374 on Linux) may specify:
 375
 376 ```toml
 377 [package]
 378 # ...
 379 links = "git2"
 380 ```
 381
 382 ### The `exclude` and `include` fields
 383
 384 The `exclude` and `include` fields can be used to explicitly specify which
 385 files are included when packaging a project to be [published][publishing],
 386 and certain kinds of change tracking (described below).
 387 The patterns specified in the `exclude` field identify a set of files that are
 388 not included, and the patterns in `include` specify files that are explicitly
 389 included.
 390 You may run [`cargo package --list`][`cargo package`] to verify which files will
 391 be included in the package.
 392
 393 ```toml
 394 [package]
 395 # ...
 396 exclude = ["/ci", "images/", ".*"]
 397 ```
 398
 399 ```toml
 400 [package]
 401 # ...
 402 include = ["/src", "COPYRIGHT", "/examples", "!/examples/big_example"]
 403 ```
 404
 405 The default if neither field is specified is to include all files from the
 406 root of the package, except for the exclusions listed below.
 407
 408 If `include` is not specified, then the following files will be excluded:
 409
 410 * If the package is not in a git repository, all "hidden" files starting with
 411   a dot will be skipped.
 412 * If the package is in a git repository, any files that are ignored by the
 413   [gitignore] rules of the repository and global git configuration will be
 414   skipped.
 415
 416 Regardless of whether `exclude` or `include` is specified, the following files
 417 are always excluded:
 418
 419 * Any sub-packages will be skipped (any subdirectory that contains a
 420   `Cargo.toml` file).
 421 * A directory named `target` in the root of the package will be skipped.
 422
 423 The following files are always included:
 424
 425 * The `Cargo.toml` file of the package itself is always included, it does not
 426   need to be listed in `include`.
 427 * A minimized `Cargo.lock` is automatically included if the package contains a
 428   binary or example target, see [`cargo package`] for more information.
 429 * If a [`license-file`](#the-license-and-license-file-fields) is specified, it
 430   is always included.
 431
 432 The options are mutually exclusive; setting `include` will override an
 433 `exclude`. If you need to have exclusions to a set of `include` files, use the
 434 `!` operator described below.
 435
 436 The patterns should be [gitignore]-style patterns. Briefly:
 437
 438 - `foo` matches any file or directory with the name `foo` anywhere in the
 439   package. This is equivalent to the pattern `**/foo`.
 440 - `/foo` matches any file or directory with the name `foo` only in the root of
 441   the package.
 442 - `foo/` matches any *directory* with the name `foo` anywhere in the package.
 443 - Common glob patterns like `*`, `?`, and `[]` are supported:
 444   - `*` matches zero or more characters except `/`.  For example, `*.html`
 445     matches any file or directory with the `.html` extension anywhere in the
 446     package.
 447   - `?` matches any character except `/`. For example, `foo?` matches `food`,
 448     but not `foo`.
 449   - `[]` allows for matching a range of characters. For example, `[ab]`
 450     matches either `a` or `b`. `[a-z]` matches letters a through z.
 451 - `**/` prefix matches in any directory. For example, `**/foo/bar` matches the
 452   file or directory `bar` anywhere that is directly under directory `foo`.
 453 - `/**` suffix matches everything inside. For example, `foo/**` matches all
 454   files inside directory `foo`, including all files in subdirectories below
 455   `foo`.
 456 - `/**/` matches zero or more directories. For example, `a/**/b` matches
 457   `a/b`, `a/x/b`, `a/x/y/b`, and so on.
 458 - `!` prefix negates a pattern. For example, a pattern of `src/*.rs` and
 459   `!foo.rs` would match all files with the `.rs` extension inside the `src`
 460   directory, except for any file named `foo.rs`.
 461
 462 The include/exclude list is also used for change tracking in some situations.
 463 For targets built with `rustdoc`, it is used to determine the list of files to
 464 track to determine if the target should be rebuilt. If the package has a
 465 [build script] that does not emit any `rerun-if-*` directives, then the
 466 include/exclude list is used for tracking if the build script should be re-run
 467 if any of those files change.
 468
 469 [gitignore]: https://git-scm.com/docs/gitignore
 470
 471 ### The `publish` field
 472
 473 The `publish` field can be used to prevent a package from being published to a
 474 package registry (like *crates.io*) by mistake, for instance to keep a package
 475 private in a company.
 476
 477 ```toml
 478 [package]
 479 # ...
 480 publish = false
 481 ```
 482
 483 The value may also be an array of strings which are registry names that are
 484 allowed to be published to.
 485
 486 ```toml
 487 [package]
 488 # ...
 489 publish = ["some-registry-name"]
 490 ```
 491
 492 If publish array contains a single registry, `cargo publish` command will use
 493 it when `--registry` flag is not specified.
 494
 495 ### The `metadata` table
 496
 497 Cargo by default will warn about unused keys in `Cargo.toml` to assist in
 498 detecting typos and such. The `package.metadata` table, however, is completely
 499 ignored by Cargo and will not be warned about. This section can be used for
 500 tools which would like to store package configuration in `Cargo.toml`. For
 501 example:
 502
 503 ```toml
 504 [package]
 505 name = "..."
 506 # ...
 507
 508 # Metadata used when generating an Android APK, for example.
 509 [package.metadata.android]
 510 package-name = "my-awesome-android-app"
 511 assets = "path/to/static"
 512 ```
 513
 514 There is a similar table at the workspace level at
 515 [`workspace.metadata`][workspace-metadata]. While cargo does not specify a
 516 format for the content of either of these tables, it is suggested that
 517 external tools may wish to use them in a consistent fashion, such as referring
 518 to the data in `workspace.metadata` if data is missing from `package.metadata`,
 519 if that makes sense for the tool in question.
 520
 521 [workspace-metadata]: workspaces.md#the-metadata-table
 522
 523 ### The `default-run` field
 524
 525 The `default-run` field in the `[package]` section of the manifest can be used
 526 to specify a default binary picked by [`cargo run`]. For example, when there is
 527 both `src/bin/a.rs` and `src/bin/b.rs`:
 528
 529 ```toml
 530 [package]
 531 default-run = "a"
 532 ```
 533
 534 #### The `lints` section
 535
 536 Override the default level of lints from different tools by assigning them to a new level in a
 537 table, for example:
 538 ```toml
 539 [lints.rust]
 540 unsafe_code = "forbid"
 541 ```
 542
 543 This is short-hand for:
 544 ```toml
 545 [lints.rust]
 546 unsafe_code = { level = "forbid", priority = 0 }
 547 ```
 548
 549 `level` corresponds to the lint levels in `rustc`:
 550 - `forbid`
 551 - `deny`
 552 - `warn`
 553 - `allow`
 554
 555 `priority` is a signed integer that controls which lints or lint groups override other lint groups:
 556 - lower (particularly negative) numbers have lower priority, being overridden
 557   by higher numbers, and show up first on the command-line to tools like
 558   `rustc`
 559
 560 To know which table under `[lints]` a particular lint belongs under, it is the part before `::` in the lint
 561 name.  If there isn't a `::`, then the tool is `rust`.  For example a warning
 562 about `unsafe_code` would be `lints.rust.unsafe_code` but a lint about
 563 `clippy::enum_glob_use` would be `lints.clippy.enum_glob_use`.
 564
 565 For example:
 566 ```toml
 567 [lints.rust]
 568 unsafe_code = "forbid"
 569
 570 [lints.clippy]
 571 enum_glob_use = "deny"
 572 ```
 573
 574 ## The `[badges]` section
 575
 576 The `[badges]` section is for specifying status badges that can be displayed
 577 on a registry website when the package is published.
 578
 579 > Note: [crates.io] previously displayed badges next to a crate on its
 580 > website, but that functionality has been removed. Packages should place
 581 > badges in its README file which will be displayed on [crates.io] (see [the
 582 > `readme` field](#the-readme-field)).
 583
 584 ```toml
 585 [badges]
 586 # The `maintenance` table indicates the status of the maintenance of
 587 # the crate. This may be used by a registry, but is currently not
 588 # used by crates.io. See https://github.com/rust-lang/crates.io/issues/2437
 589 # and https://github.com/rust-lang/crates.io/issues/2438 for more details.
 590 #
 591 # The `status` field is required. Available options are:
 592 # - `actively-developed`: New features are being added and bugs are being fixed.
 593 # - `passively-maintained`: There are no plans for new features, but the maintainer intends to
 594 #   respond to issues that get filed.
 595 # - `as-is`: The crate is feature complete, the maintainer does not intend to continue working on
 596 #   it or providing support, but it works for the purposes it was designed for.
 597 # - `experimental`: The author wants to share it with the community but is not intending to meet
 598 #   anyone's particular use case.
 599 # - `looking-for-maintainer`: The current maintainer would like to transfer the crate to someone
 600 #   else.
 601 # - `deprecated`: The maintainer does not recommend using this crate (the description of the crate
 602 #   can describe why, there could be a better solution available or there could be problems with
 603 #   the crate that the author does not want to fix).
 604 # - `none`: Displays no badge on crates.io, since the maintainer has not chosen to specify
 605 #   their intentions, potential crate users will need to investigate on their own.
 606 maintenance = { status = "..." }
 607 ```
 608
 609 ## Dependency sections
 610
 611 See the [specifying dependencies page](specifying-dependencies.md) for
 612 information on the `[dependencies]`, `[dev-dependencies]`,
 613 `[build-dependencies]`, and target-specific `[target.*.dependencies]` sections.
 614
 615 ## The `[profile.*]` sections
 616
 617 The `[profile]` tables provide a way to customize compiler settings such as
 618 optimizations and debug settings. See [the Profiles chapter](profiles.md) for
 619 more detail.
 620
 621
 622
 623 [`cargo init`]: ../commands/cargo-init.md
 624 [`cargo new`]: ../commands/cargo-new.md
 625 [`cargo package`]: ../commands/cargo-package.md
 626 [`cargo run`]: ../commands/cargo-run.md
 627 [crates.io]: https://crates.io/
 628 [docs.rs]: https://docs.rs/
 629 [publishing]: publishing.md
 630 [Rust Edition]: ../../edition-guide/index.html
 631 [spdx-2.1-license-expressions]: https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60
 632 [spdx-license-list-3.11]: https://github.com/spdx/license-list-data/tree/v3.11
 633 [SPDX site]: https://spdx.org/license-list
 634 [TOML]: https://toml.io/
 635
 636 <script>
 637 (function() {
 638     var fragments = {
 639         "#the-project-layout": "../guide/project-layout.html",
 640         "#examples": "cargo-targets.html#examples",
 641         "#tests": "cargo-targets.html#tests",
 642         "#integration-tests": "cargo-targets.html#integration-tests",
 643         "#configuring-a-target": "cargo-targets.html#configuring-a-target",
 644         "#target-auto-discovery": "cargo-targets.html#target-auto-discovery",
 645         "#the-required-features-field-optional": "cargo-targets.html#the-required-features-field",
 646         "#building-dynamic-or-static-libraries": "cargo-targets.html#the-crate-type-field",
 647         "#the-workspace-section": "workspaces.html#the-workspace-section",
 648         "#virtual-workspace": "workspaces.html",
 649         "#package-selection": "workspaces.html#package-selection",
 650         "#the-features-section": "features.html#the-features-section",
 651         "#rules": "features.html",
 652         "#usage-in-end-products": "features.html",
 653         "#usage-in-packages": "features.html",
 654         "#the-patch-section": "overriding-dependencies.html#the-patch-section",
 655         "#using-patch-with-multiple-versions": "overriding-dependencies.html#using-patch-with-multiple-versions",
 656         "#the-replace-section": "overriding-dependencies.html#the-replace-section",
 657         "#package-metadata": "manifest.html#the-package-section",
 658         "#the-authors-field-optional": "manifest.html#the-authors-field",
 659         "#the-edition-field-optional": "manifest.html#the-edition-field",
 660         "#the-documentation-field-optional": "manifest.html#the-documentation-field",
 661         "#the-workspace--field-optional": "manifest.html#the-workspace-field",
 662         "#package-build": "manifest.html#the-build-field",
 663         "#the-build-field-optional": "manifest.html#the-build-field",
 664         "#the-links-field-optional": "manifest.html#the-links-field",
 665         "#the-exclude-and-include-fields-optional": "manifest.html#the-exclude-and-include-fields",
 666         "#the-publish--field-optional": "manifest.html#the-publish-field",
 667         "#the-metadata-table-optional": "manifest.html#the-metadata-table",
 668     };
 669     var target = fragments[window.location.hash];
 670     if (target) {
 671         var url = window.location.toString();
 672         var base = url.substring(0, url.lastIndexOf('/'));
 673         window.location.replace(base + "/" + target);
 674     }
 675 })();
 676 </script>