11

I have a dependency in my Cargo file that needs to be different by platform, specifically, the default features. Here's what I am trying to do:

[package]
name = "..blah.."
version = "..blah.."
authors = ["..blah.."]

[target.'cfg(target_os = "macos")'.dependencies]
hyper = { version = "0.9", default-features = false, features = ["security-framework"] }

[target.'cfg(target_os = "linux")'.dependencies]
hyper = { version = "0.9", default-features = true }

But this doesn't seem to do what I want. On my Mac it appears to be using the bottom target line as if I just specified hyper = "0.9". If I do cargo build as specified, I get errors with regard to openssl:

cargo:warning=#include <openssl/ssl.h>

However, if I build it like this:

[dependencies]
hyper = { version = "0.9", default-features = false, features = ["security-framework"] }

Then it builds fine. This indicates to me that the cfg for "macos" isn't working.

How do I make this work, or more specifically, how do I solve the problem where I need my dependency to use different features by platform?

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
vcsjones
  • 138,677
  • 31
  • 291
  • 286
  • 1
    Why is this not a duplicate of http://stackoverflow.com/q/29854912/155423? – Shepmaster Sep 26 '16 at 18:24
  • I guess it is not a duplicate because the syntax above seems to match the examples in the [unit tests](https://github.com/rust-lang/cargo/blob/master/tests/cfg.rs) and [commit](https://github.com/rust-lang/cargo/pull/2328/commits/f5d786e05600720ba4671caf5b598624103c8f72). – wimh Sep 26 '16 at 18:33
  • 2
    @Shepmaster well in theory they are trying to solve the same problem, so I suppose my question then is "Why isn't my Cargo file selecting the right configuration for a dependency". – vcsjones Sep 26 '16 at 18:47
  • @wimh I don't think I'm following. The [unit tests you linked to say](https://github.com/rust-lang/cargo/blob/4f57637fbeb9a79c86808609e388a1eed9a50e2f/tests/cfg.rs#L152) `[target."cfg(windows)".dependencies]`, **without** `target_os`. The [documentation likewise does not use `target_os`](http://doc.crates.io/specifying-dependencies.html#platform-specific-dependencies). – Shepmaster Sep 26 '16 at 18:48
  • 2
    @Shepmaster [here](https://github.com/alexcrichton/curl-rust/blob/master/Cargo.toml) is an example which uses `target_os`, although in a `not`. The configurations should be the same as used in `#[cfg(...)]`, where `target_os` is listed in the [documentation](https://doc.rust-lang.org/reference.html#conditional-compilation). – wimh Sep 26 '16 at 18:55
  • I'm suffering from the same issue… did you manage to solve it? –  Oct 21 '16 at 09:30
  • @lunaryorn nope. I've been meaning to file an issue on the Cargo GitHub repository. – vcsjones Oct 21 '16 at 13:07
  • @vcsjones I think it's a bug, so it'd be great if you could open an issue! If you do could you CC me? I've got the same username on Github. –  Oct 21 '16 at 13:10
  • Doesn't MacOS contain a Linux shell? I believe the Linux dependency is overriding the MacOS dependency by coming later in the list. Try swapping the dependencies around. – Toothbrush Oct 27 '16 at 09:00

1 Answers1

1

It does not look like it is possible with Rust 1.13.0 and Cargo 0.13.0-nightly. See Cargo issues 3195 and 1197.

As a workaround, you can tell Cargo to use Homebrew's OpenSSL:

export OPENSSL_INCLUDE_DIR=`brew --prefix openssl`/include
export OPENSSL_LIB_DIR=`brew --prefix openssl`/lib
export DEP_OPENSSL_INCLUDE=`brew --prefix openssl`/include
Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
big_gie
  • 2,829
  • 3
  • 31
  • 45
  • Using Homebrew's OpenSSL is also documented [here on SO](http://stackoverflow.com/q/34612395/155423), but I don't think that will help OP. Specifically, I believe they wish to *avoid using OpenSSL* on macOS, and use the built-in SSL framework instead. – Shepmaster Dec 02 '16 at 03:45
  • Yes, that's why I said it was not possible for the moment and that the rest was a workaround. For my use case, I prefer my crate to compile without manual modifications to `Cargo.toml` rather than commenting/uncommenting a line in it to link against the framework... Bu tI agree it's not optimal and does not solve the issue. – big_gie Dec 02 '16 at 03:53