[EXPERIMENT]: Use Windows sys bindings and add raw-dylib feature#126913
Closed
ChrisDenton wants to merge 3 commits intorust-lang:masterfrom
Closed
[EXPERIMENT]: Use Windows sys bindings and add raw-dylib feature#126913ChrisDenton wants to merge 3 commits intorust-lang:masterfrom
sys bindings and add raw-dylib feature#126913ChrisDenton wants to merge 3 commits intorust-lang:masterfrom
Conversation
rustbot
added
O-windows
Member
Author
|
@bors try |
Collaborator
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 24, 2024
[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.
Collaborator
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-author
rustbot
added
A-testsuite
This comment has been minimized.
This comment has been minimized.
Contributor
|
That's the only reason the "std" option still exists. 😊 |
Member
Author
|
@bors try |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 24, 2024
[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
Collaborator
This comment has been minimized.
This comment has been minimized.
Collaborator
|
💔 Test failed - checks-actions |
Member
Author
|
@petrochenkov it's not super important but would you happen to know why imports aren't de-deduplicating in this case? |
Member
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 |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 25, 2024
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
compiler-errors
added a commit
to compiler-errors/rust
that referenced
this pull request
Jun 25, 2024
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`
matthiaskrgr
added a commit
to matthiaskrgr/rust
that referenced
this pull request
Jun 25, 2024
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``
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 26, 2024
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``
Member
Author
|
Thanks for the quick fix! Let's try this again... @bors try |
Collaborator
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jun 26, 2024
[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
Collaborator
|
☀️ Try build successful - checks-actions |
Member
Author
|
Success! 🎉 I'll close this experiment for now and open a new PR when there's a crates.io release. |
flip1995
pushed a commit
to flip1995/rust-clippy
that referenced
this pull request
Jun 28, 2024
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``
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
With recent changes in win32metadata and windows-rs we should no longer need a special
-stdbindings. Additionally, this adds awindows-raw-dylibfeature that allows users ofbuild-stdto 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