-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Lift up workspace rlibs while building #3478
Merged
Merged
Conversation
This file contains 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
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
☔ The latest upstream changes (presumably #3468) made this pull request unmergeable. Please resolve the merge conflicts. |
I think the condition here was slightly off from before, so invert it subtly to get what we want, lifting up anything in a workspace or binaries otherwise. Closes rust-lang#3432
@bors r+ |
📌 Commit 3cbf141 has been approved by |
bors
added a commit
that referenced
this pull request
Jan 12, 2017
Lift up workspace rlibs while building I think the condition here was slightly off from before, so invert it subtly to get what we want, lifting up anything in a workspace or binaries otherwise. Closes #3432
☀️ Test successful - status-appveyor, status-travis |
This was referenced Feb 7, 2017
bors
added a commit
that referenced
this pull request
Mar 13, 2021
Fix logic for determining prefer-dynamic for a dylib. The logic for determining if a dylib should use `prefer-dynamic` used to be something like "do not use prefer-dynamic if it is the current package". The current logic has a strange behavior where it works as intended if there is only one package in the workspace, but a workspace with multiple packages will always use `prefer-dynamic`. Instead of using `current_opt`, which isn't a good concept to use in a workspace, I switched this to be "primary" (a package selected on the command-line). **History** * 9879a0a Initial prefer-dynamic behavior. * #3221 changed to the faulty logic (see comments at #3221 (comment)). I think there was some confusion there. * #3478 fixed the logic for one of the changed conditions, but not the one for prefer-dynamic
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
I think the condition here was slightly off from before, so invert it subtly to
get what we want, lifting up anything in a workspace or binaries otherwise.
Closes #3432