Add support for cdylib crate types #2741
Conversation
|
r? @wycats (rust_highfive has picked a reviewer for you, use r? to override) |
|
☔ The latest upstream changes (presumably #2743) made this pull request unmergeable. Please resolve the merge conflicts. |
| let suffix = match parts.next() { | ||
| Some(part) => part, | ||
| None => bail!("output of --print=file-names has change in \ | ||
| the compiler, cannot parse"), |
|
r=me |
And while we're at it this also extends support for all future crate types assuming that they aren't linkable by default.
|
@bors: r=brson |
|
📌 Commit 3f7b09c has been approved by |
Add support for cdylib crate types And while we're at it this also extends support for all future crate types assuming that they aren't linkable by default.
|
☀️ Test successful - cargo-cross-linux, cargo-linux-32, cargo-linux-64, cargo-mac-32, cargo-mac-64, cargo-win-gnu-32, cargo-win-gnu-64, cargo-win-msvc-32, cargo-win-msvc-64 |
|
Will this commit be included in whatever version of cargo is shipped with rust 1.10? It's currently not in the 1.10 beta (that's using |
|
Unfortunately, no, this didn't make that train |
|
Any chance of a backport? I wouldn't want to rush in something if it's not ready, but it'll be a bummer to see |
|
Unfortunately we don't have a backport process in place for Cargo so we can't do that just yet, but it'll certainly be in 1.11! |
And while we're at it this also extends support for all future crate types
assuming that they aren't linkable by default.