Skip to content
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

Merged
merged 5 commits into from
Jun 2, 2020

Conversation

seritools
Copy link
Contributor

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)

@rust-highfive
Copy link
Collaborator

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.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label May 27, 2020
Copy link
Member

@Mark-Simulacrum Mark-Simulacrum left a 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.

src/tools/remote-test-server/src/main.rs Outdated Show resolved Hide resolved
@nikomatsakis
Copy link
Contributor

Good example where I would want to ping the windows group, once it's setup. For now, cc @retep998 and @rylev to check briefly the assertions about PATH and LD_LIBRARY_PATH above.

r=me otherwise.

@seritools
Copy link
Contributor Author

seritools commented May 28, 2020

Just for reference: DLL Search Order for Desktop Applications

EDIT: Similar handling for DLL loading here

@rylev
Copy link
Member

rylev commented May 28, 2020

Pinging @kennykerr and @sivadeilra as well.

@retep998
Copy link
Member

The PATH handling looks fine to me.

@kennykerr
Copy link
Contributor

Looks good.

@Mark-Simulacrum
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented May 28, 2020

📌 Commit 94b7d27d3b7b59a55cf7ee66709cebeb25ea99ae has been approved by Mark-Simulacrum

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 28, 2020
dst
}

#[cfg(not(windows))]
fn set_permissions(path: &Path) {
t!(fs::set_permissions(&dst, Permissions::from_mode(0o755)));
Copy link
Contributor

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

Copy link
Contributor Author

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?)

Copy link
Contributor

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

Copy link
Contributor Author

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

@seritools
Copy link
Contributor Author

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 )

@Mark-Simulacrum
Copy link
Member

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+

@bors
Copy link
Contributor

bors commented May 29, 2020

📌 Commit 36d6791 has been approved by Mark-Simulacrum

@seritools
Copy link
Contributor Author

Gotcha, thanks!

Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this pull request May 29, 2020
…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)
RalfJung added a commit to RalfJung/rust that referenced this pull request May 30, 2020
…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)
@RalfJung
Copy link
Member

Failed in #72786 (comment).
@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels May 30, 2020
@seritools
Copy link
Contributor Author

seritools commented May 31, 2020

Wow, the error seems weird :S Can't see any reason why this shouldn't run on arm-unknown-linux-gnueabihf. (Exact CI log line here)

I've manually compiled and opened for that target it via cross inside a linux/WSL2 VM and it behaves just like it should, only panicking if the parameter is missing or invalid. I don't see however how that parameter could be either of that, it's unconditionally added by compiletest. I didn't find any other location where the remote-test-client is called, either :(

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?

r? @Mark-Simulacrum

@Mark-Simulacrum
Copy link
Member

Oh, I forgot -- I think we also need to update

format!("{} run", builder.tool_exe(Tool::RemoteTestClient).display()),
and
let tool = builder.tool_exe(Tool::RemoteTestClient);
which both call remote-test-client outside of compiletest.

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.

@seritools
Copy link
Contributor Author

Ohh, now everything makes sense!

The arguments will be passed to the runner with the executable to run as the last argument.

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 0 should be fine.

About the second occurrence (l. 1891): That one is for the spawn-emulator subcommand which is unchanged though all of this.

`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)
Since cargo appends executable/args, the support_lib count
parameter has to come first.
@seritools
Copy link
Contributor Author

seritools commented May 31, 2020

Alright! Let's give it another shot if everything looks good.
@Mark-Simulacrum

@Mark-Simulacrum
Copy link
Member

@bors r+ rollup=never

@bors
Copy link
Contributor

bors commented May 31, 2020

📌 Commit 036da3a has been approved by Mark-Simulacrum

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 31, 2020
@Dylan-DPC-zz
Copy link

@bors p=1

@bors
Copy link
Contributor

bors commented Jun 2, 2020

⌛ Testing commit 036da3a with merge eeaf497...

@bors
Copy link
Contributor

bors commented Jun 2, 2020

☀️ Test successful - checks-azure
Approved by: Mark-Simulacrum
Pushing eeaf497 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Jun 2, 2020
@bors bors merged commit eeaf497 into rust-lang:master Jun 2, 2020
@seritools seritools deleted the remote-test-windows branch June 2, 2020 12:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.