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

Lift up workspace rlibs while building #3478

Merged
merged 1 commit into from
Jan 12, 2017
Merged

Conversation

alexcrichton
Copy link
Member

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

@rust-highfive
Copy link

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

@bors
Copy link
Contributor

bors commented Jan 5, 2017

☔ 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
@brson
Copy link
Contributor

brson commented Jan 12, 2017

@bors r+

@bors
Copy link
Contributor

bors commented Jan 12, 2017

📌 Commit 3cbf141 has been approved by brson

@bors
Copy link
Contributor

bors commented Jan 12, 2017

⌛ Testing commit 3cbf141 with merge 4b351ea...

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
@bors
Copy link
Contributor

bors commented Jan 12, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: brson
Pushing 4b351ea to master...

@bors bors merged commit 3cbf141 into rust-lang:master Jan 12, 2017
@alexcrichton alexcrichton deleted the lift branch January 19, 2017 18:50
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
@ehuss ehuss added this to the 1.16.0 milestone Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

No output library created when using workspaces
5 participants