-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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