Move the manifest part to the new chapter.

src/manifest.md → src/03-02-manifest.md

@@ -1,6 +1,6 @@
-% The Manifest Format
+## The Manifest Format
 
-# The `[package]` section
+### The `[package]` section
 
 The first section in a `Cargo.toml` is `[package]`.
 
@@ -13,7 +13,7 @@ authors = ["you@example.com"]
 
 All three of these fields are mandatory.
 
-## The `version` field
+#### The `version` field
 
 Cargo bakes in the concept of [Semantic
 Versioning](http://semver.org/), so make sure you follow some basic rules:
@@ -27,7 +27,7 @@ Versioning](http://semver.org/), so make sure you follow some basic rules:
   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)
+#### 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
@@ -41,7 +41,7 @@ building native code. More information can be found in the build script
 build = "build.rs"
 ```
 
-## The `exclude` and `include` fields (optional)
+#### The `exclude` and `include` fields (optional)
 
 You can explicitly specify to Cargo that a set of [globs][globs] should be
 ignored or included for the purposes of packaging and rebuilding a package. The
@@ -71,7 +71,7 @@ necessary source files may not be included.
 
 [globs]: http://doc.rust-lang.org/glob/glob/struct.Pattern.html
 
-## The `publish`  field (optional)
+#### The `publish`  field (optional)
 
 The `publish` field can be used to prevent a package from being published to a
 repository by mistake.
@@ -82,7 +82,7 @@ repository by mistake.
 publish = false
 ```
 
-## The `workspace`  field (optional)
+#### The `workspace`  field (optional)
 
 The `workspace` field can be used to configure the workspace that this package
 will be a member of. If not specified this will be inferred as the first
@@ -96,7 +96,7 @@ workspace = "path/to/root"
 
 For more information, see the documentation for the workspace table below.
 
-## Package metadata
+#### Package metadata
 
 There are a number of optional metadata fields also accepted under the
 `[package]` section:
@@ -161,7 +161,7 @@ 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 `metadata` table (optional)
+#### The `metadata` table (optional)
 
 Cargo by default will warn about unused keys in `Cargo.toml` to assist in
 detecting typos and such. The `package.metadata` table, however, is completely
@@ -180,13 +180,13 @@ package-name = "my-awesome-android-app"
 assets = "path/to/static"
 ```
 
-# Dependency sections
+### Dependency sections
 
 See the [specifying dependencies page](specifying-dependencies.html) for
 information on the `[dependencies]`, `[dev-dependencies]`, and target-specific
 `[target.*.dependencies]` sections.
 
-# The `[profile.*]` sections
+### 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
@@ -252,7 +252,7 @@ codegen-units = 1
 panic = 'unwind'
 ```
 
-# The `[features]` section
+### The `[features]` section
 
 Cargo supports features to allow expression of:
 
@@ -313,7 +313,7 @@ default-features = false # do not include the default features, and optionally
 features = ["secure-password", "civet"]
 ```
 
-## Rules
+#### Rules
 
 The usage of features is subject to a few rules:
 
@@ -335,7 +335,7 @@ Note that it is explicitly allowed for features to not actually activate any
 optional dependencies. This allows packages to internally enable/disable
 features without requiring a new dependency.
 
-## Usage in end products
+#### Usage in end products
 
 One major use-case for this feature is specifying optional features in
 end-products. For example, the Servo project may want to include optional
@@ -350,7 +350,7 @@ $ cargo build --release --features "shumway pdf"
 
 Default features could be excluded using `--no-default-features`.
 
-## Usage in packages
+#### Usage in packages
 
 In most cases, the concept of *optional dependency* in a library is best
 expressed as a separate package that the top-level application depends on.
@@ -377,7 +377,7 @@ In almost all cases, it is an antipattern to use these features outside of
 high-level packages that are designed for curation. If a feature is optional, it
 can almost certainly be expressed as a separate package.
 
-# The `[workspace]` section
+### The `[workspace]` section
 
 Projects can define a workspace which is a set of crates that will all share the
 same `Cargo.lock` and output directory. The `[workspace]` table can be defined
@@ -429,7 +429,8 @@ and also be a member crate of another workspace (contain `package.workspace`).
 Most of the time workspaces will not need to be dealt with as `cargo new` and
 `cargo init` will handle workspace configuration automatically.
 
-# The project layout
+#TODO: move this to a more appropriate place
+### The project layout
 
 If your project is an executable, name the main source file `src/main.rs`. If it
 is a library, name the main source file `src/lib.rs`.
@@ -454,15 +455,18 @@ integration tests, and benchmarks respectively.
   *.rs
 ```
 
-To structure your code after you've created the files and folders for your project, you should remember to use Rust's module system, which you can read about in [the book](https://doc.rust-lang.org/book/crates-and-modules.html).
+To structure your code after you've created the files and folders for your
+project, you should remember to use Rust's module system, which you can read
+about in [the book](https://doc.rust-lang.org/book/crates-and-modules.html).
 
-# Examples
+### Examples
 
 Files located under `examples` are example uses of the functionality provided by
 the library. When compiled, they are placed in the `target/examples` directory.
 
-They can compile either as executables (with a `main()` function) or libraries and pull in the library by using `extern crate <library-name>`. They are compiled when you run
-your tests to protect them from bitrotting.
+They can compile either as executables (with a `main()` function) or libraries
+and pull in the library by using `extern crate <library-name>`. They are
+compiled when you run your tests to protect them from bitrotting.
 
 You can run individual executable examples with the command `cargo run --example
 <example-name>`.
@@ -475,9 +479,10 @@ name = "foo"
 crate-type = ["staticlib"]
 ```
 
-You can build individual library examples with the command `cargo build --example <example-name>`.
+You can build individual library examples with the command `cargo build
+--example <example-name>`.
 
-# Tests
+### Tests
 
 When you run `cargo test`, Cargo will:
 
@@ -489,7 +494,7 @@ When you run `cargo test`, Cargo will:
 * compile and run your library’s [integration tests](#integration-tests); and
 * compile your library’s examples.
 
-## Integration tests
+#### Integration tests
 
 Each file in `tests/*.rs` is an integration test. When you run `cargo test`,
 Cargo will compile each of these files as a separate crate. The crate can link
@@ -502,7 +507,7 @@ example, if you want several integration tests to share some code, you can put
 the shared code in `tests/common/mod.rs` and then put `mod common;` in each of
 the test files.
 
-# Configuring a target
+### Configuring a target
 
 All of the  `[[bin]]`, `[lib]`, `[[bench]]`, `[[test]]`, and `[[example]]`
 sections support similar configuration for specifying how a target should be
@@ -556,7 +561,7 @@ proc-macro = false
 harness = true
 ```
 
-## The `required-features` field (optional)
+#### The `required-features` field (optional)
 
 The `required-features` field specifies which features the target needs in order
 to be built. If any of the required features are not selected, the target will
@@ -575,7 +580,7 @@ tools = []
 required-features = ["postgres", "tools"]
 ```
 
-# Building dynamic or static libraries
+#### Building dynamic or static libraries
 
 If your project produces a library, you can specify which kind of library to
 build by explicitly listing the library in your `Cargo.toml`:
@@ -596,7 +601,7 @@ includes them.
 You can read more about the different crate types in the
 [Rust Reference Manual](https://doc.rust-lang.org/reference.html#linkage)
 
-# The `[replace]` Section
+### The `[replace]` Section
 
 This section of Cargo.toml can be used to [override dependencies][replace] with
 other copies. The syntax is similar to the `[dependencies]` section:

src/SUMMARY.md

@@ -13,8 +13,8 @@
     * [Continuous Integration](02-07-continuous-integration.md)
 * [Cargo In Depth](cargo-in-depth.md)
     * [Specifying Dependencies](03-01-specifying-dependencies.md)
+    * [Cargo.toml Format](03-02-manifest.md)
     * [Publishing on crates.io](crates-io.md)
-    * [Cargo.toml Format](manifest.md)
     * [Build Scripts](build-scripts.md)
     * [Configuration](config.md)
     * [Package ID specs](pkgid-spec.md)

src/cargo-in-depth.md

@@ -1,3 +1,4 @@
 ## Cargo In Depth
 
 * [Specifying Dependencies](03-01-specifying-dependencies.html)
+* [Cargo.toml Format](03-02-manifest.html)