Add a --build-dir flag to rustbuild
#98745
Conversation
rust-highfive
added
the
S-waiting-on-review
jyn514
added
the
T-bootstrap
There was a problem hiding this comment.
Thanks for your detailed writeup! The nice thing about doing it this way is --build-dir vscode will work for everyone :) and we can start recommending that in the dev-guide for people who have enough disk space.
@Mark-Simulacrum this is simple to revert so I'm going to go ahead and unilaterally approve - feel free to leave a comment if you think we should avoid doing this for some reason.
|
@bors r+ rollup |
|
📌 Commit 79f8dc0 has been approved by |
bors
added
S-waiting-on-bors
|
This seems probably okay - I don't have any direct objections. I personally do this by modifying the current directory in the rust-analyzer command and passing --config to a config.toml, which works fine today already. But this seems a little simpler, and probably slightly easier to integrate cross platform. So I think this is probably good. |
…askrgr Rollup of 9 pull requests Successful merges: - rust-lang#98610 (fix `emit_inference_failure_err` ICE) - rust-lang#98640 (Let rust-analyzer ship on stable, non-preview) - rust-lang#98686 (add ice test for 46511) - rust-lang#98727 (rustdoc: filter '_ lifetimes from ty::PolyTraitRef) - rust-lang#98729 (clarify that ExactSizeIterator::len returns the remaining length) - rust-lang#98733 (Request to be notified of MIR changes) - rust-lang#98734 (Update RELEASES.md) - rust-lang#98745 (Add a `--build-dir` flag to rustbuild) - rust-lang#98749 (Add macro_rules! rustdoc change to 1.62 relnotes) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
This adds an optional
--build-dir <path>flag to rustbuild (to both the python and rust code in src/bootstrap). If provided, it overrides build directory from the config file (if any was provided).My reason for wanting this is that I often will make a change, save, and then go run
x.py checkorx.py test(or something). Because I've saved, vscode will start doing its thing in the background, but this will take the file lock, preventingx.pyfrom running until vscode finishes whatever it's doing (since the manually invoked x.py won't be able to acquire said file lock). This is annoying, because I'd rather the command I explicitly invoke not wait for r-a to complete, as r-a's check is conceptually a background task (and one which can take quite some time to complete).Anyway, while there are likely other ways this could be handled, if you have the disk space an easy way is to just have vscode be configured to use a different build directory, and then they never have to block each-other.
This can currently be arranged without this patch, by maintaining two
config.tomls, one of which has a different build dir, and just exists to be passed into the overridden check command in vscode.Unfortunately, this has the downside of requiring I maintain two
config.tomls and keep them (at least somewhat) in sync, aside from the build dir. I dislike for several reasons, not the least of which because I know myself well enough to know that these will inevitably get out of sync and confuse me in the future (perhaps this case would be different since I've thought about it enough to write this patch? Who knows, I'd rather not find out).Either way, it would be much easier for me to have a way for only the build directory to differ, which this patch provides by way of a new flag. I suggested this to @jyn514 who indicated it sounded reasonable so long as it didn't add too much complexity, which I think I've achieved, but he can be the judge.
Anyway, with this patch I can just use something like
["python3", "x.py", "check", "--build-dir", "build-vscode", "--json-output"]as the overridden check command to rust-analyzer, and do not need to futz with any additionalconfig.tomls. Which is very nice!I've tested this manually, and can confirm that it works. I'm not sure if it needs automated tests, or where I should add them if so.
r? @jyn514 (who has had to put up with my complaints about this... many times. <3)