subdirectories you mention, to refer to each other; then it runs
cargo; and then it puts everything back.
-Telling nailing-cargo how to massage Cargo.toml
------------------------------------------------
+Telling nailing-cargo how to massage `Cargo.toml`
+-------------------------------------------------
To find the subdirectories, and the packages, it looks for `subdirs`
and `packages` in `Cargo.nail`.
* `-D`: Increase amount of debugging dump.
- * `-n`: "No action": stop after writing Cargo.toml.nailing~
+ * `-n`: "No action": stop after writing `Cargo.toml.nailing~`
everywhere, and do not run any build command.
* `-A<arch>` | `--arch=<arch>` | `--target=<arch>`
* `-u` | `--cargo-lock-update` | `-U` | `--no-cargo-lock-update`
- Enables, or disables, the dance to allow Cargo.lock (or
+ Enables, or disables, the dance to allow `Cargo.lock` (or
alternative) to be updated in the source directory.
- With this dance enabled the Cargo.lock and Cargo.toml are
+ With this dance enabled the `Cargo.lock` and `Cargo.toml` are
copied to the build directory along with a skeleton just big
enough to fool cargo. After cargo has run, the resulting
- Cargo.lock is copied back to the source tree.
+ `Cargo.lock` is copied back to the source tree.
This makes no sense with in-tree builds.
Alternative `Cargo.lock` filename
---------------------------------
-To control use of alternative Cargo.lock filename, use the section
+To control use of alternative `Cargo.lock` filename, use the section
`[alt_cargolock]`. Settings here:
* `file = false`: disables this feature
* Out of tree builds require a unified filesystem view: eg, different
users on the same host, NFS, or something. This could be improved.
- The alternative Cargo.lock filename must currently be a leafname. I
+ The alternative `Cargo.lock` filename must currently be a leafname. I
think fixing this just involves review to check other values work
properly.
- * The alternative Cargo.lock file must be on same filesystem. This is
+ * The alternative `Cargo.lock` file must be on same filesystem. This is
not so easy to fix; we would want the existing algorithm but a
fallback for this case.
- * Cargo.nail is unconditionally looked for in the parent directory.
+ * `Cargo.nail` is unconditionally looked for in the parent directory.
Ideally this should be configurable, and also perhaps be able to
- combine multiple Cargo.nail files? Relatedly, although
+ combine multiple `Cargo.nail` files? Relatedly, although
nailing-cargo can read multiple config files, it can only handle
one file specifying directories and packages.