Add a tool to run x.py from any subdirectory

[casey]

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, 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.

[rust-highfive]

r? @Mark-Simulacrum

(rust_highfive has picked a reviewer for you, use r? to override)

[jyn514]

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.

[casey]

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.

[casey]

Thanks for the review! I think I addressed everything.

[Mark-Simulacrum]

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?

[Mark-Simulacrum]

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.

[jyn514]

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)

Could we not make it part of the workspace, so it doesn't need to resolve any project other than its own directory?

[Mark-Simulacrum]

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.

[jyn514]

We could always add it to the workspace if we figure out the submodule problem later.

[camelid]

I think the name x, is not a common binary name. There is X, I think usually a shortcut that launches X11, but on a case-sensitive system, there isn't any conflict.

I want to note that macOS is unfortunately case-insensitive, so this doesn’t hold for macOS.

[jyn514]

@camelid X11 isn't installed on MacOS, though, right?

[camelid]

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 x or X.

[jyn514]

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.

[jyn514]

@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.

[casey]

I checked on windows, and ctrl-c seems to work when running the wrapper.

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.

[Mark-Simulacrum]

@bors r+ rollup

Thanks!

[bors]

📌 Commit 5fc22f1 has been approved by Mark-Simulacrum

[casey]

Nice! Thank you all for reviewing ^_^

[jyn514]

@casey do you mind making that PR to the dev-guide?

[casey]

@jyn514 Yup, definitely, it's on my todo list.

[casey]

I just opened rust-lang/rustc-dev-guide#945 to document this.