-
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
Upgrade rustup used on AppVeyor #3996
Conversation
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
I've totally forgotten the error, let's find out what it is again! @bors: r+ |
📌 Commit 3e1ed70 has been approved by |
⌛ Testing commit 3e1ed70 with merge 655a073... |
💔 Test failed - status-appveyor |
@bors: r+ |
📌 Commit 4ff9b5e has been approved by |
💔 Test failed - status-appveyor |
@bors: r+ |
📌 Commit d869907 has been approved by |
⌛ Testing commit d869907 with merge eae061f... |
💔 Test failed - status-travis |
@bors: retry
…On Fri, May 5, 2017 at 11:06 AM, bors ***@***.***> wrote:
💔 Test failed - status-travis
<https://travis-ci.org/rust-lang/cargo/builds/229144620?utm_source=github_status&utm_medium=notification>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#3996 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAD95BkT-BcOSyqk54s1qZ38WhfsNpkZks5r20jwgaJpZM4NRQ33>
.
|
☀️ Test successful - status-appveyor, status-travis |
fix `cargo test` of dylib projects for end user runs too Fixes running `cargo test` and `cargo test --target <target>` for dylib projects. Moves the logic just landed in #3996 into cargo itself, so cargo sets the dylib path for anyone running `cargo test` or `cargo run`. Current master sets the dylib path only for `cargo test` on cargo itself. This PR pins to rustup 1.2.0 for the purposes of testing. If rust-lang/rustup#1093 ends up working out, then this PR would only be important for non-rustup users and people doing cross testing, `cargo test --target <target>`. Arguably https://github.com/mcgoo/cargo/blob/ed273851f8bc76f726eda4a2e2a7bb470c3718bc/src/cargo/ops/cargo_rustc/context.rs#L249-L253 should point to lib/rustlib/\<host triple\>/lib instead of sysroot/lib, because I think if the libs are different, you will never be able to compile a working plugin anyway, and for the host=target case you get the lib/rustlib/\<host triple\>/lib anyhow. Is there ever a case where the lib/rustlib/\<host triple\>/lib and sysroot/lib versions of the libs would be expected to differ? This is not a huge deal for me one way or the other - it doesn't impact my workflow at all. I nearly dropped it when I saw @alexcrichton had made it all work in 3996, but I think it's worth doing because it removes a surprise. It certainly would have saved me a couple of days of confusion. Either way, thanks for looking it over.
No description provided.