Should accept positional arguments after flags #38373
Labels
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
steveklabnik
added
the
T-bootstrap
steveklabnik
changed the title
steveklabnik
added
the
T-compiler
|
If my PR is accepted, then this is fixed. ;-) |
frewsxcv
added a commit
to frewsxcv/rust
that referenced
this issue
Apr 6, 2017
…hton Overhaul Bootstrap (x.py) Command-Line-Parsing & Help Output While working on rust-lang#40417, I got frustrated with the behavior of x.py and the bootstrap binary it wraps, so I decided to do something about it. This PR should improve documentation, make the command-line-parsing more flexible, and clean up some of the internals. No command that worked before should stop working. At least that's the theory. :-) This should resolve at least rust-lang#40920 and rust-lang#38373. Changes: - No more manual args manipulation -- getopts used everywhere except the one place it's not possible. As a result, options can be in any position, now, even before the subcommand. - The additional options for test, bench, and dist now appear in the help output. - No more single-letter variable bindings used internally for large scopes. - Don't output the time measurement when just invoking `x.py` or explicitly passing `-h` or `--help` - Logic is now much more linear. We build strings up, and then print them. - Refer to subcommands as subcommands everywhere (some places we were saying "command") - Other minor stuff. @alexcrichton This is my first PR. Do I need to do something specific to request reviewers or anything?
frewsxcv
added a commit
to frewsxcv/rust
that referenced
this issue
Apr 6, 2017
…hton Overhaul Bootstrap (x.py) Command-Line-Parsing & Help Output While working on rust-lang#40417, I got frustrated with the behavior of x.py and the bootstrap binary it wraps, so I decided to do something about it. This PR should improve documentation, make the command-line-parsing more flexible, and clean up some of the internals. No command that worked before should stop working. At least that's the theory. :-) This should resolve at least rust-lang#40920 and rust-lang#38373. Changes: - No more manual args manipulation -- getopts used everywhere except the one place it's not possible. As a result, options can be in any position, now, even before the subcommand. - The additional options for test, bench, and dist now appear in the help output. - No more single-letter variable bindings used internally for large scopes. - Don't output the time measurement when just invoking `x.py` or explicitly passing `-h` or `--help` - Logic is now much more linear. We build strings up, and then print them. - Refer to subcommands as subcommands everywhere (some places we were saying "command") - Other minor stuff. @alexcrichton This is my first PR. Do I need to do something specific to request reviewers or anything?
|
Based on testing today, this is fixed -- closing. |
|
:-) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Consider a command line invocation like this:
It has the most commonly edited arguments somewhere middle in the command line, and the least edited – on the sides. Instead I would, so editing the command would be very quick:
but it fails with an error:
(unrelatedly, it seems like its usage is also kinda wrong)
The text was updated successfully, but these errors were encountered: