<commit_before>% The Manifest Format

# The `[package]` Section

The first section in a `Cargo.toml` is `[package]`.

```toml
[package]
name = "hello_world" # the name of the package
version = "0.0.1"    # the current version, obeying semver
authors = [ "<EMAIL>" ]
```

All three of these fields are mandatory. Cargo bakes in the concept of
[Semantic Versioning](http://semver.org/), so make sure you follow some
basic rules:

* Before you reach 1.0.0, anything goes.
* After 1.0.0, only make breaking changes when you increment the major
  version. In Rust, breaking changes include adding fields to structs or
  variants to enums. Don't break the build.
* After 1.0.0, don't add any new public API (no new `pub` anything) in
  tiny versions. Always increment the minor version if you add any new
  `pub` structs, traits, fields, types, functions, methods or anything else.
* Use version numbers with three numeric parts such as 1.0.0 rather than 1.0.

## The `build` Field (optional)

This field specifies a file in the repository which is a [build
script][1] for building native code. More information can be
found in the build script [guide][1].

[1]: build-script.html

```toml
[package]
# ...
build = "build.rs"
```

## The `exclude` Field (optional)

You can explicitly specify to Cargo that a set of globs should be ignored for
the purposes of packaging and rebuilding a package. The globs specified in this
field identify a set of files that are not included when a package is published
as well as ignored for the purposes of detecting when to rebuild a package.

If a VCS is being used for a package, the `exclude` field will be seeded with
the VCS's ignore settings (`.gitignore` for git for example).

```toml
[package]
# ...
exclude = ["build/**/*.o", "doc/**/*.html"]
```

## Package metadata

There are a number of optional metadata fields also accepted under the
`[package]` section:

```toml
[package]
# ...

# A short blurb about the package. This is not rendered in any format when
# uploaded to crates.io (aka this is not markdown)
description = "..."

# These URLs point to more information about the repository
documentation = "..."
homepage = "..."
repository = "..."

# This points to a file in the repository (relative to this Cargo.toml). The
# contents of this file are stored and indexed in the registry.
readme = "..."

# This is a small list of keywords used to categorize and search for this
# package.
keywords = ["...", "..."]

# This is a string description of the license for this package. Currently
# crates.io will validate the license provided against a whitelist of known
# license identifiers from http://spdx.org/licenses/. Multiple licenses can
# be separated with a `/`
license = "..."

# If a project is using a nonstandard license, then this key may be specified in
# lieu of the above key and must point to a file relative to this manifest
# (similar to the readme key)
license-file = "..."
```

The [crates.io](https://crates.io) registry will render the description, display
the license, link to the three URLs and categorize by the keywords. These keys
provide useful information to users of the registry and also influence the
search ranking of a crate. It is highly discouraged to omit everything in a
published crate.


# The `[dependencies.*]` Sections

You list dependencies using `[dependencies.<name>]`. For example, if you
wanted to depend on both `hammer` and `color`:

```toml
[package]
# ...

[dependencies.hammer]
version = "0.5.0" # optional
git = "https://github.com/wycats/hammer.rs"

[dependencies.color]
git = "https://github.com/bjz/color-rs"
```

You can specify the source of a dependency in one of two ways at the moment:

* `git = "<git-url>"`: A git repository with a `Cargo.toml` in its root. The
  `rev`, `tag`, and `branch` options are also recognized to use something other
  than the `master` branch.
* `path = "<relative-path>"`: A path relative to the current `Cargo.toml`
  with a `Cargo.toml` in its root.

Dependencies from crates.io are not declared with separate sections:

```toml
[dependencies]
hammer = "0.5.0"
color = "0.6.0"
```

Platform-specific dependencies take the same format, but are listed under the
`target.$triple` section:

```toml
[target.x86_64-unknown-linux-gnu.dependencies]
openssl = "1.0.1"

[target.x86_64-pc-windows-gnu.dependencies]
winhttp = "0.4.0"
```

# The `[profile.*]` Sections

Cargo supports custom configuration of how rustc is invoked through **profiles**
at the top level. Any manifest may declare a profile, but only the **top level**
project's profiles are actually read. All dependencies' profiles will be
overridden. This is done so the top-level project has control over how its
dependencies are compiled.

There are five currently supported profile names, all of which have the same
configuration available to them. Listed below is the configuration available,
along with the defaults for each profile.

```toml
# The development profile, used for `cargo build`
[profile.dev]
opt-level = 0  # Controls the --opt-level the compiler builds with
debug = true   # Controls whether the compiler passes -g or `--cfg ndebug`
rpath = false  # Controls whether the compiler passes `-C rpath`
lto = false    # Controls `-C lto` for binaries and staticlibs<commit_msg>Auto merge of #1282 - vrinek:master, r=alexcrichton<commit_after>% The Manifest Format

# The `[package]` Section

The first section in a `Cargo.toml` is `[package]`.

```toml
[package]
name = "hello_world" # the name of the package
version = "0.0.1"    # the current version, obeying semver
authors = [ "<EMAIL>" ]
```

All three of these fields are mandatory. Cargo bakes in the concept of
[Semantic Versioning](http://semver.org/), so make sure you follow some
basic rules:

* Before you reach 1.0.0, anything goes.
* After 1.0.0, only make breaking changes when you increment the major
  version. In Rust, breaking changes include adding fields to structs or
  variants to enums. Don't break the build.
* After 1.0.0, don't add any new public API (no new `pub` anything) in
  tiny versions. Always increment the minor version if you add any new
  `pub` structs, traits, fields, types, functions, methods or anything else.
* Use version numbers with three numeric parts such as 1.0.0 rather than 1.0.

## The `build` Field (optional)

This field specifies a file in the repository which is a [build
script][1] for building native code. More information can be
found in the build script [guide][1].

[1]: build-script.html

```toml
[package]
# ...
build = "build.rs"
```

## The `exclude` Field (optional)

You can explicitly specify to Cargo that a set of globs should be ignored for
the purposes of packaging and rebuilding a package. The globs specified in this
field identify a set of files that are not included when a package is published
as well as ignored for the purposes of detecting when to rebuild a package.

If a VCS is being used for a package, the `exclude` field will be seeded with
the VCS's ignore settings (`.gitignore` for git for example).

```toml
[package]
# ...
exclude = ["build/**/*.o", "doc/**/*.html"]
```

## Package metadata

There are a number of optional metadata fields also accepted under the
`[package]` section:

```toml
[package]
# ...

# A short blurb about the package. This is not rendered in any format when
# uploaded to crates.io (aka this is not markdown)
description = "..."

# These URLs point to more information about the repository
documentation = "..."
homepage = "..."
repository = "..."

# This points to a file in the repository (relative to this Cargo.toml). The
# contents of this file are stored and indexed in the registry.
readme = "..."

# This is a small list of keywords used to categorize and search for this
# package.
keywords = ["...", "..."]

# This is a string description of the license for this package. Currently
# crates.io will validate the license provided against a whitelist of known
# license identifiers from http://spdx.org/licenses/. Multiple licenses can
# be separated with a `/`
license = "..."

# If a project is using a nonstandard license, then this key may be specified in
# lieu of the above key and must point to a file relative to this manifest
# (similar to the readme key)
license-file = "..."
```

The [crates.io](https://crates.io) registry will render the description, display
the license, link to the three URLs and categorize by the keywords. These keys
provide useful information to users of the registry and also influence the
search ranking of a crate. It is highly discouraged to omit everything in a
published crate.


# The `[dependencies.*]` Sections

You list dependencies using `[dependencies.<name>]`. For example, if you
wanted to depend on both `hammer` and `color`:

```toml
[package]
# ...

[dependencies.hammer]
version = "0.5.0" # optional
git = "https://github.com/wycats/hammer.rs"

[dependencies.color]
git = "https://github.com/bjz/color-rs"
```

You can specify the source of a dependency in one of two ways at the moment:

* `git = "<git-url>"`: A git repository with a `Cargo.toml` in its root. The
  `rev`, `tag`, and `branch` options are also recognized to use something other
  than the `master` branch.
* `path = "<relative-path>"`: A path relative to the current `Cargo.toml`
  with a `Cargo.toml` in its root.

Dependencies from crates.io are not declared with separate sections:

```toml
[dependencies]
hammer = "0.5.0"
color = "0.6.0"
```

The syntax of the requirement strings is described in the [crates.io guide](crates-io.html#using-crates.io-based-crates).

Platform-specific dependencies take the same format, but are listed under the
`target.$triple` section:

```toml
[target.x86_64-unknown-linux-gnu.dependencies]
openssl = "1.0.1"

[target.x86_64-pc-windows-gnu.dependencies]
winhttp = "0.4.0"
```

# The `[profile.*]` Sections

Cargo supports custom configuration of how rustc is invoked through **profiles**
at the top level. Any manifest may declare a profile, but only the **top level**
project's profiles are actually read. All dependencies' profiles will be
overridden. This is done so the top-level project has control over how its
dependencies are compiled.

There are five currently supported profile names, all of which have the same
configuration available to them. Listed below is the configuration available,
along with the defaults for each profile.

```toml
# The development profile, used for `cargo build`
[profile.dev]
opt-level = 0  # Controls the --opt-level the compiler builds with
debug = true   # Controls whether the compiler passes -g or `--cfg ndebug`
rpath = false  # Controls whether the compiler passes `-C rpath`
lto = false    # Controls `-C lto` for binaries and staticlibs
{'fraction_non_alphanumeric': 0.10101574876525952, 'fraction_numerical': 0.008573292330630882, 'mean_word_length': 4.007932804479702, 'pattern_counts': {'":': 0, '<': 11, '<?xml version=': 0, '>': 11, 'https://': 6, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4397940', 'n_tokens_mistral': 3191, 'n_tokens_neox': 3024, 'n_words': 1494}