Add a tool to run x.py from any subdirectory#78658
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
jyn514
added
T-bootstrap
|
Assuming this is accepted, can you also make a PR to the rustc-dev-guide documenting how to use it? It would go in https://rustc-dev-guide.rust-lang.org/building/how-to-build-and-run.html. |
Yup, definitely, I'd be happy to. |
|
Thanks for the review! I think I addressed everything. |
Mark-Simulacrum
left a comment
Mark-Simulacrum
left a comment
There was a problem hiding this comment.
I am a bit worried this might break the process group creation on Windows where we attempt to associate rustbuild with the Python process (IIRC) -- can you check if ctrl+c on Windows when running through this tool kills Cargo and any running rustc processes?
|
I am generally okay with adding this but if it's a cargo project you won't be able to run it (in general) without running x.py first unless you're manually managing submodules (otherwise Cargo.toml will not resolve). I am a bit hesitant as a result to add it. But not really opposed, it seems low maintenance cost, modulo my comments on Windows process scheduling. |
Could we not make it part of the workspace, so it doesn't need to resolve any project other than its own directory? |
|
That would work, I think, yes. I suppose the downside is that we can't make it the default-run in the workspace, but since that's not a good idea anyway due to the submodule problem, seems fine. Please also squash commits. |
|
We could always add it to the workspace if we figure out the submodule problem later. |
I want to note that macOS is unfortunately case-insensitive, so this doesn’t hold for macOS. |
|
@camelid X11 isn't installed on MacOS, though, right? |
|
I don't think it's installed by default, but people may install it themselves (see also XQuartz). I just wanted to note that macOS is case-insensitive, so this will collide with anything named |
|
I think that's a reasonable tradeoff - you'd have to install both of the binaries yourself, at which point you'd know that they overlap. |
|
@casey I think this is waiting on you to remove src/tools/x from the workspace and test that it can be run without first running x.py. |
camelid
added
S-waiting-on-author
This adds a binary called `x` in `src/tools/x`. All it does is check the current directory and its ancestors for a file called `x.py`, and if it finds one, runs it. By installing x, you can easily `x.py` from any subdirectory. It can be installed globally with `cargo install --path src/tools/x`
|
I checked on windows, and I removed it from the workspace, and added it to the exclude list. It now works when run in a fresh checkout, before submodules are initialized. I also squashed the commits. |
camelid
added
S-waiting-on-review
|
@bors r+ rollup Thanks! |
|
📌 Commit 5fc22f1 has been approved by |
bors
added
S-waiting-on-bors
Add a tool to run `x.py` from any subdirectory This adds a binary called `x` in `src/tools/x`. All it does is check the current directory and its ancestors for a file called `x.py`, and if it finds one, runs it. By installing x, you can easily run `x.py` from any subdirectory, and only need to type `x`. It can be installed with `cargo install --path src/tools/x` This is a copy of a [binary I've been using myself when working on rust](https://github.com/casey/bootstrap), currently published to crates.io as `bootstrap`. It could be changed to avoid indirecting through `x.py`, and instead call the bootstrap module directly. However, this seemed like the simplest thing possible, and won't break if the details of how the bootstrap module is invoked change.
Add a tool to run `x.py` from any subdirectory This adds a binary called `x` in `src/tools/x`. All it does is check the current directory and its ancestors for a file called `x.py`, and if it finds one, runs it. By installing x, you can easily run `x.py` from any subdirectory, and only need to type `x`. It can be installed with `cargo install --path src/tools/x` This is a copy of a [binary I've been using myself when working on rust](https://github.com/casey/bootstrap), currently published to crates.io as `bootstrap`. It could be changed to avoid indirecting through `x.py`, and instead call the bootstrap module directly. However, this seemed like the simplest thing possible, and won't break if the details of how the bootstrap module is invoked change.
Add a tool to run `x.py` from any subdirectory This adds a binary called `x` in `src/tools/x`. All it does is check the current directory and its ancestors for a file called `x.py`, and if it finds one, runs it. By installing x, you can easily run `x.py` from any subdirectory, and only need to type `x`. It can be installed with `cargo install --path src/tools/x` This is a copy of a [binary I've been using myself when working on rust](https://github.com/casey/bootstrap), currently published to crates.io as `bootstrap`. It could be changed to avoid indirecting through `x.py`, and instead call the bootstrap module directly. However, this seemed like the simplest thing possible, and won't break if the details of how the bootstrap module is invoked change.
Add a tool to run `x.py` from any subdirectory This adds a binary called `x` in `src/tools/x`. All it does is check the current directory and its ancestors for a file called `x.py`, and if it finds one, runs it. By installing x, you can easily run `x.py` from any subdirectory, and only need to type `x`. It can be installed with `cargo install --path src/tools/x` This is a copy of a [binary I've been using myself when working on rust](https://github.com/casey/bootstrap), currently published to crates.io as `bootstrap`. It could be changed to avoid indirecting through `x.py`, and instead call the bootstrap module directly. However, this seemed like the simplest thing possible, and won't break if the details of how the bootstrap module is invoked change.
Add a tool to run `x.py` from any subdirectory This adds a binary called `x` in `src/tools/x`. All it does is check the current directory and its ancestors for a file called `x.py`, and if it finds one, runs it. By installing x, you can easily run `x.py` from any subdirectory, and only need to type `x`. It can be installed with `cargo install --path src/tools/x` This is a copy of a [binary I've been using myself when working on rust](https://github.com/casey/bootstrap), currently published to crates.io as `bootstrap`. It could be changed to avoid indirecting through `x.py`, and instead call the bootstrap module directly. However, this seemed like the simplest thing possible, and won't break if the details of how the bootstrap module is invoked change.
Rollup of 19 pull requests Successful merges: - rust-lang#76097 (Stabilize hint::spin_loop) - rust-lang#76227 (Stabilize `Poll::is_ready` and `is_pending` as const) - rust-lang#78065 (make concurrency helper more pleasant to read) - rust-lang#78570 (Remove FIXME comment in print_type_sizes ui test suite) - rust-lang#78572 (Use SOCK_CLOEXEC and accept4() on more platforms.) - rust-lang#78658 (Add a tool to run `x.py` from any subdirectory) - rust-lang#78706 (Fix run-make tests running when LLVM is disabled) - rust-lang#78728 (Constantify `UnsafeCell::into_inner` and related) - rust-lang#78775 (Bump Rustfmt and RLS) - rust-lang#78788 (Correct unsigned equivalent of isize to be usize) - rust-lang#78811 (Make some std::io functions `const`) - rust-lang#78828 (use single char patterns for split() (clippy::single_char_pattern)) - rust-lang#78841 (Small cleanup in `TypeFoldable` derive macro) - rust-lang#78842 (Honor the rustfmt setting in config.toml) - rust-lang#78843 (Less verbose debug logging from inlining integrator) - rust-lang#78852 (Convert a bunch of intra-doc links) - rust-lang#78860 (rustc_resolve: Use `#![feature(format_args_capture)]`) - rust-lang#78861 (typo and formatting) - rust-lang#78865 (Don't fire `CONST_ITEM_MUTATION` lint when borrowing a deref) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
|
Nice! Thank you all for reviewing ^_^ |
|
@casey do you mind making that PR to the dev-guide? |
|
@jyn514 Yup, definitely, it's on my todo list. |
|
I just opened rust-lang/rustc-dev-guide#945 to document this. |
8 participants
This adds a binary called
xinsrc/tools/x. All it does is check the current directory and its ancestors for a file calledx.py, and if it finds one, runs it.By installing x, you can easily run
x.pyfrom any subdirectory, and only need to typex.It can be installed with
cargo install --path src/tools/xThis is a copy of a binary I've been using myself when working on rust, currently published to crates.io as
bootstrap.It could be changed to avoid indirecting through
x.py, and instead call the bootstrap module directly. However, this seemed like the simplest thing possible, and won't break if the details of how the bootstrap module is invoked change.