-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make remote-test-client and remote-test-server compatible with windows #72672
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't be sure this is correct for Windows, but it largely seems fine to me. Left one nit.
d566ef7
to
94b7d27
Compare
Just for reference: DLL Search Order for Desktop Applications EDIT: Similar handling for DLL loading here |
Pinging @kennykerr and @sivadeilra as well. |
The |
Looks good. |
@bors r+ |
📌 Commit 94b7d27d3b7b59a55cf7ee66709cebeb25ea99ae has been approved by |
dst | ||
} | ||
|
||
#[cfg(not(windows))] | ||
fn set_permissions(path: &Path) { | ||
t!(fs::set_permissions(&dst, Permissions::from_mode(0o755))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think dst
should be path
here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Argh, yes! Really gotta setup WSL2 or a VM to test this, will do that later today.
(Is there a way to quickly run the equivalent of cargo check for different targets that don't support building form the host?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can use cross
e.g.
cross check --target x86_64-unknown-linux-gnu
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, will check it out later today
94b7d27
to
36d6791
Compare
What's the correct procedure here? I guess bors is gonna fail the merge when trying to test anything that's tested via the remote server. Can the new commit be re-submitted before it has to do all of that? 😅 ( @nikomatsakis ) |
It's automatically removed from queue if new commits are pushed, though there is the edge case of already being in a rollup. I think we're all good here though, so let's @bors r+ |
📌 Commit 36d6791 has been approved by |
Gotcha, thanks! |
…rk-Simulacrum Make remote-test-client and remote-test-server compatible with windows `compiletest` and `remote-test-client`: The command line for `remote-test-client` was changed slightly to allow cross-platform compatible paths. The old way of supplying the support libs was by joining their paths with the executable path with `:`. This caused Windows-style paths to be split after the directory letter. Now, the number of support libs is provided as a parameter as well, and the support lib paths are split off from the regular args in the client. `remote-test-server`: - Marked Unix-only parts as such and implemented Windows alternatives - On Windows `LD_LIBRARY_PATH` doesn't exist. Libraries are loaded from `PATH` though, so that's the way around it. - Tiny cleanup: `Command::args`/`envs` instead of manually looping over them - The temp path for Windows has to be set via environment variable, since there isn't a global temp directory that would work on every machine (as a static string)
…rk-Simulacrum Make remote-test-client and remote-test-server compatible with windows `compiletest` and `remote-test-client`: The command line for `remote-test-client` was changed slightly to allow cross-platform compatible paths. The old way of supplying the support libs was by joining their paths with the executable path with `:`. This caused Windows-style paths to be split after the directory letter. Now, the number of support libs is provided as a parameter as well, and the support lib paths are split off from the regular args in the client. `remote-test-server`: - Marked Unix-only parts as such and implemented Windows alternatives - On Windows `LD_LIBRARY_PATH` doesn't exist. Libraries are loaded from `PATH` though, so that's the way around it. - Tiny cleanup: `Command::args`/`envs` instead of manually looping over them - The temp path for Windows has to be set via environment variable, since there isn't a global temp directory that would work on every machine (as a static string)
Failed in #72786 (comment). |
36d6791
to
f07a093
Compare
Wow, the error seems weird :S Can't see any reason why this shouldn't run on I've manually compiled and opened for that target it via While testing I've noticed that the client has a help text that I didn't update before, so I've done that to align it with the new parameters. Any ideas? |
Oh, I forgot -- I think we also need to update Line 1773 in 4512721
Line 1891 in 4512721
I'm not sure what the second place there is doing but the first one is using cargo's support for test runners, loosely documented here -- https://doc.rust-lang.org/nightly/cargo/reference/config.html?highlight=runner#targettriplerunner -- though as we're setting the environment variable I suspect we can't use arrays. |
Ohh, now everything makes sense!
Because of this I think we have to move the submodule count before the executable, should be doable :) It doesn't seem like the cargo runner has a way of supplying support libs anyways, so setting it to About the second occurrence (l. 1891): That one is for the |
`compiletest` and `remote-test-client`: The command line for `remote-test-client` was changed slightly to allow cross-platform compatible paths. The old way of supplying the support libs was by joining their paths with the executable path with `:`. This caused Windows-style paths to be split after the directory letter. Now, the number of support libs is provided as a parameter as well, and the support lib paths are split off from the regular args in the client. `remote-test-server`: - Marked Unix-only parts as such and implemented Windows alternatives - On Windows `LD_LIBRARY_PATH` doesn't exist. Libraries are loaded from `PATH` though, so that's the way around it. - Tiny cleanup: `Command::args`/`envs` instead of manually looping over them - The temp path for Windows has to be set via environment variable, since there isn't a global temp directory that would work on every machine (as a static string)
f07a093
to
5f179c1
Compare
Since cargo appends executable/args, the support_lib count parameter has to come first.
5f179c1
to
036da3a
Compare
Alright! Let's give it another shot if everything looks good. |
@bors r+ rollup=never |
📌 Commit 036da3a has been approved by |
@bors p=1 |
☀️ Test successful - checks-azure |
compiletest
andremote-test-client
:The command line for
remote-test-client
was changed slightly to allow cross-platform compatible paths. The old way of supplying the support libs was by joining their paths with the executable pathwith
:
. This caused Windows-style paths to be split after the directory letter. Now, the number of support libs is provided as a parameter as well, and the support lib paths are split off from the regular args in the client.remote-test-server
:LD_LIBRARY_PATH
doesn't exist. Libraries are loaded fromPATH
though, so that's the way around it.Command::args
/envs
instead of manually looping over them