then in the builtin arch alias list. The builtin list is
equivalent to: `[arch]` `RPI='arm-unknown-linux-gnueabihf'`.
- * <a name="s_subcommand">`-s<subcommand>`</a>
+ * `-o` | `--online` | `-O` | `--offline`
- Behave as if the build command were `cargo <subcommand>`.
- This influences the logic which tries to determine which
- options to pass to cargo, whether cargo needs to be online, and
- whether cargo might want to update `Cargo.lock`.
+ Whether to allow cargo to make network access. nailing-cargo
+ always passes `--offline` to cargo, unless `--online` is in
+ force. The default value depends on the configuration and the
+ cargo subcommand - see [`[misc]` `online`](#misc_online),
+ under Configuration.
- nailing-cargo knows about `update`, `generate-lockfile` and
- `fetch`; all other subcommands are (silently) treated the same way
- as `build` (ie, no subcommand properties). See
- [`--subcommand-props`](#subcommand_props) for more detail about how the
- subcommand affects nailing-cargo's behaviour.
+ * `-u` | `--cargo-lock-update` | `-U` | `--no-cargo-lock-update`
- The default is to use the cargo subcommand found from parsing
- nailing-cargo's command line. NB: `-s` does not affect
- which build command (and which cargo subcommand) is actually run.
+ 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
+ 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.
+
+ This makes no sense with in-tree builds.
+
+ Default is no update unless the cargo subcommand will want it.
* `-c` | `-C`
rather than a non-cargo build command (usage 3). `-C` and `-c`
do not affect the parsing of nailing-cargo's command line.
- * `-o` | `--online` | `-O` | `--offline`
-
- Whether to allow cargo to make network access. nailing-cargo
- always passes `--offline` to cargo, unless `--online` is in
- force. The default value depends on the configuration and the
- cargo subcommand - see [`[misc]` `online`](#misc_online),
- under Configuration.
-
- * `-u` | `--cargo-lock-update` | `-U` | `--no-cargo-lock-update`
-
- Enables, or disables, the dance to allow `Cargo.lock` (or
- alternative) to be updated in the source directory.
+ * <a name="s_subcommand">`-s<subcommand>`</a>
- 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.
+ Behave as if the build command were `cargo <subcommand>`.
+ This influences the logic which tries to determine which
+ options to pass to cargo, whether cargo needs to be online, and
+ whether cargo might want to update `Cargo.lock`.
- This makes no sense with in-tree builds.
+ nailing-cargo knows about `update`, `generate-lockfile` and
+ `fetch`; all other subcommands are (silently) treated the same way
+ as `build` (ie, no subcommand properties). See
+ [`--subcommand-props`](#subcommand_props) for more detail about how the
+ subcommand affects nailing-cargo's behaviour.
- Default is no update unless the cargo subcommand will want it.
+ The default is to use the cargo subcommand found from parsing
+ nailing-cargo's command line. NB: `-s` does not affect
+ which build command (and which cargo subcommand) is actually run.
* <a name="subcommand_props">`--subcommand-props=<prop>,...`</a>