-
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
[EXPERIMENT]: Use Windows sys
bindings and add raw-dylib feature
#126913
Conversation
@bors try |
[EXPERIMENT]: Use Windows `sys` bindings and add raw-dylib feature With recent changes in win32metadata and windows-rs we should no longer need a special `-std` bindings. Additionally, this adds a `windows-raw-dylib` feature that allows users of `build-std` to experiment with using `raw-dylib`. The feature isn't yet complete because there are a few other crates that contribute imports (alloc and backtrace). This PR will currently fail CI's tidy test due to using a git dependency. cc `@kennykerr,` just to notify you I'm experimenting with this try-job: x86_64-msvc r? ghost
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
This comment has been minimized.
This comment has been minimized.
That's the only reason the "std" option still exists. 😊 |
@bors try |
[EXPERIMENT]: Use Windows `sys` bindings and add raw-dylib feature With recent changes in win32metadata and windows-rs we should no longer need a special `-std` bindings. Additionally, this adds a `windows-raw-dylib` feature that allows users of `build-std` to experiment with using `raw-dylib`. The feature isn't yet complete because there are a few other crates that contribute imports (alloc and backtrace). This PR will currently fail CI's tidy test due to using a git dependency. cc `@kennykerr,` just to notify you I'm experimenting with this try-job: x86_64-msvc try-job: i686-msvc try-job: i686-mingw try-job: x86_64-mingw r? ghost
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
@petrochenkov it's not super important but would you happen to know why imports aren't de-deduplicating in this case? |
it's probably because the de-duplication logic1 takes into account the "kind" part of the import, which I assume is different between the two the simplest fix would probably be moving the de-duplication logic one step further (ie just after the Footnotes |
De-duplicate all consecutive native libs regardless of their options Address rust-lang#126913 (comment) by no longer de-duplicating based on the "options" but by only looking at the generated link args, as to avoid consecutive libs that originated from different native-lib with different options (like `raw-dylib` on Windows) but isn't relevant for `--print=native-static-libs`. r? `@petrochenkov` try-job: x86_64-msvc
De-duplicate all consecutive native libs regardless of their options Address rust-lang#126913 (comment) by no longer de-duplicating based on the "options" but by only looking at the generated link args, as to avoid consecutive libs that originated from different native-lib with different options (like `raw-dylib` on Windows) but isn't relevant for `--print=native-static-libs`. r? `@petrochenkov`
De-duplicate all consecutive native libs regardless of their options Address rust-lang#126913 (comment) by no longer de-duplicating based on the "options" but by only looking at the generated link args, as to avoid consecutive libs that originated from different native-lib with different options (like `raw-dylib` on Windows) but isn't relevant for `--print=native-static-libs`. r? ``@petrochenkov``
Rollup merge of rust-lang#126943 - Urgau:dedup-all, r=petrochenkov De-duplicate all consecutive native libs regardless of their options Address rust-lang#126913 (comment) by no longer de-duplicating based on the "options" but by only looking at the generated link args, as to avoid consecutive libs that originated from different native-lib with different options (like `raw-dylib` on Windows) but isn't relevant for `--print=native-static-libs`. r? ``@petrochenkov``
Thanks for the quick fix! Let's try this again... @bors try |
[EXPERIMENT]: Use Windows `sys` bindings and add raw-dylib feature With recent changes in win32metadata and windows-rs we should no longer need a special `-std` bindings. Additionally, this adds a `windows-raw-dylib` feature that allows users of `build-std` to experiment with using `raw-dylib`. The feature isn't yet complete because there are a few other crates that contribute imports (alloc and backtrace). This PR will currently fail CI's tidy test due to using a git dependency. cc `@kennykerr,` just to notify you I'm experimenting with this try-job: x86_64-msvc try-job: i686-msvc try-job: i686-mingw try-job: x86_64-mingw r? ghost
☀️ Try build successful - checks-actions |
Success! 🎉 I'll close this experiment for now and open a new PR when there's a crates.io release. |
De-duplicate all consecutive native libs regardless of their options Address rust-lang/rust#126913 (comment) by no longer de-duplicating based on the "options" but by only looking at the generated link args, as to avoid consecutive libs that originated from different native-lib with different options (like `raw-dylib` on Windows) but isn't relevant for `--print=native-static-libs`. r? ``@petrochenkov``
With recent changes in win32metadata and windows-rs we should no longer need a special
-std
bindings. Additionally, this adds awindows-raw-dylib
feature that allows users ofbuild-std
to experiment with usingraw-dylib
. The feature isn't yet complete because there are a few other crates that contribute imports (alloc and backtrace). This PR will currently fail CI's tidy test due to using a git dependency.cc @kennykerr, just to notify you I'm experimenting with this
try-job: x86_64-msvc
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-mingw
r? ghost