Add --list to known subcommands. #719
Conversation
|
Hmm, im not sure if this is the correct behaviour, since the list may not actually be what we support |
My mistake, since commands like |
|
I don't know what should be expected here. Maybe a compromise of first showing actually supported commands (e.g commands run in container), and then a list of those that are run on the host |
|
I feel that might be the best solution, since then we get the supported subcommands for both cross and the host cargo, and it correctly handles edge-cases like The current output is: So maybe the output should be something like: |
|
Ok I've implemented the requested changes, and a sample output is as follows: The logic is explained in the commit message, but basically, it captures the list of subcommands from |
Alexhuszagh
force-pushed
the
list
branch
2 times, most recently
from
9d3277c
to
f21a604
Compare
|
Ok I've implemented the above changes and I've added the OutputExt trait for this purpose, which implements pub trait OutputExt {
fn stdout(&self) -> Result<String>;
}
impl OutputExt for std::process::Output {
fn stdout(&self) -> Result<String> {
String::from_utf8(self.stdout.clone())
.wrap_err_with(|| format!("`{:?}` output was not UTF-8", self))
}
}Next, I implemented /// Runs the command to completion and returns its stdout
fn run_and_get_stdout(&mut self, verbose: bool) -> Result<String> {
let out = self.run_and_get_output(verbose)?;
self.status_result(out.status)?;
out.stdout()
}
/// Runs the command to completion and returns the status and its stdout.
fn run_and_get_output(&mut self, verbose: bool) -> Result<std::process::Output> {
self.print_verbose(verbose);
self.output()
.wrap_err_with(|| format!("couldn't execute `{:?}`", self))
.map_err(Into::into)
}The rest is just trivial changes. However, this is mostly your code, so you should probably get credit for it? One major difference I've added is |
Doesn't matter to me, if you want you could add
to the commit message |
src/extensions.rs
Outdated
| /// Runs the command to completion and returns the status and its stdout. | ||
| fn run_and_get_output(&mut self, verbose: bool) -> Result<std::process::Output> { |
There was a problem hiding this comment.
| /// Runs the command to completion and returns the status and its stdout. | |
| fn run_and_get_output(&mut self, verbose: bool) -> Result<std::process::Output> { | |
| /// Runs the command to completion and returns the status and its [output](std::process::Output). | |
| /// | |
| /// # Notes | |
| /// | |
| /// This command does not check the status. | |
| fn run_and_get_output(&mut self, verbose: bool) -> Result<std::process::Output> { |
|
bors r+ |
719: Add --list to known subcommands. r=Alexhuszagh a=Alexhuszagh `cross --list` should list the subcommands present for cargo in the image, rather on the host. This works because any option provided before a subcommand has priority over the subcommand. For example, `cargo build --help` prints the help menu for `cargo build`, but `cargo --help build` ignores `build` and prints the help for `cargo`. Therefore, the options `--help`, `--version`, and `--list` can be treated as pseudo-subcommands. Fixes #715. Co-authored-by: Alex Huszagh <ahuszagh@gmail.com>
|
Build failed: |
|
Hmm both I believe the |
src/main.rs
Outdated
| } | ||
| Ok(out.status) | ||
| } | ||
| None | Some(Subcommand::Other) => cargo::run(&argv, verbose), |
There was a problem hiding this comment.
Should be the universal match arm, since we can fall back to the host cargo if the image doesn't exist or if the target isn't supported (the two failing examples above).
_ => cargo::run(&argv, verbose),
`cross --list` should list the subcommands present for cargo in the
image, rather on the host. This works because any option provided before
a subcommand has priority over the subcommand. For example, `cargo build
--help` prints the help menu for `cargo build`, but `cargo --help build`
ignores `build` and prints the help for `cargo`. Therefore, the options
`--help`, `--version`, and `--list` can be treated as pseudo-subcommands.
This works by capturing the output subcommand list, and then classifying them
as either subcommands from the host or container. This also future proofs
our logic, if we ever get support for custom subcommands, since only `Other`
(unrecognized) subcommands are treated as host commands.
Sample Output:
```
Cross Commands:
b alias: build
bench Execute all benchmarks of a local package
Host Commands:
afl
asm
clean Remove artifacts that cargo has generated in the past
```
Co-authored-by: Emil Gardström <emil.gardstrom@gmail.com>
Fixes cross-rs#715.
|
bors try |
tryBuild succeeded: |
|
bors r+ |
|
Build succeeded: |
cross --listshould list the subcommands present for cargo in the image, rather on the host. This works because any option provided before a subcommand has priority over the subcommand. For example,cargo build --helpprints the help menu forcargo build, butcargo --help buildignoresbuildand prints the help forcargo. Therefore, the options--help,--version, and--listcan be treated as pseudo-subcommands.Fixes #715.