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

Port to windows-sys #5201

Closed
kennykerr opened this issue Nov 16, 2022 · 7 comments · Fixed by #5204
Closed

Port to windows-sys #5201

kennykerr opened this issue Nov 16, 2022 · 7 comments · Fixed by #5204
Labels
A-tokio Area: The main tokio crate C-feature-request Category: A feature request. M-net Module: tokio/net

Comments

@kennykerr
Copy link
Contributor

I noticed that all of the tokio dependencies have already made the switch to windows-sys, so I thought I'd take a stab at porting tokio itself just to confirm that there aren't any gaps.

https://github.com/kennykerr/tokio/pull/1/files

All tests pass as far as I can tell. There are some doc dependencies on winapi which I'm not too sure about, otherwise I'd submit a PR. Anyway, just thought I'd point you to my port in case someone wants to pursue it further.

@kennykerr kennykerr added A-tokio Area: The main tokio crate C-feature-request Category: A feature request. labels Nov 16, 2022
@Darksonn Darksonn added the M-net Module: tokio/net label Nov 16, 2022
@Darksonn
Copy link
Contributor

Considering that all of our dependencies have switched, I think it is reasonable that we switch too.

@davidbarsky
Copy link
Member

Speaking not as a reviewer, but instead a consumer of Tokio, windows-sys is moving to rust's not-yet-stabilized raw-dylib. This is particularly impactful for my employer, as vendoring windows-sys requires stripping out all the #[link] arguments for complicated, Buck-related reasons. Would it be possible to have a feature hidden behind tokio_unstable that breaks MSRV to use a version of windows-sys that uses raw-dylib?

(I'm genuinely unsure whether rustflags can influence dependency resolution, and if it can, whether it is a good idea from a maintenance perspective.)

@kennykerr
Copy link
Contributor Author

raw-dylib support is modeled after tokio_unstable and is offered via the windows_raw_dylib flag.

microsoft/windows-rs#2164

@davidbarsky
Copy link
Member

I didn't realize that you were the one responsible for that change! Thanks so much for doing that. raw_dylib support in windows-sys is going to make vendoring windows-sys a lot a lot easier.

@Darksonn
Copy link
Contributor

Would it be possible to have a feature hidden behind tokio_unstable that breaks MSRV to use a version of windows-sys that uses raw-dylib?

If windows-sys plans to unconditionally use features that require a very recent MSRV, then that's something we should be very aware of when deciding whether we should use it. But it sounds like this is not the case?

@kennykerr
Copy link
Contributor Author

Right, this will continue to be an opt-in for windows-sys via the windows_raw_dylib flag for the foreseeable future to avoid requiring a major MSRV bump.

@kennykerr
Copy link
Contributor Author

I went ahead and ported the examples and docs as well. Here's a PR: #5204

Feel free to close if you would prefer to manage the port yourself. 😊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tokio Area: The main tokio crate C-feature-request Category: A feature request. M-net Module: tokio/net
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants