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

Target-specific features #1197

Open
alexcrichton opened this issue Jan 20, 2015 · 20 comments
Open

Target-specific features #1197

alexcrichton opened this issue Jan 20, 2015 · 20 comments
Assignees
Labels

Comments

@alexcrichton
Copy link
Member

@alexcrichton alexcrichton commented Jan 20, 2015

It would be nice to support target-specific features for cases such as when certain functionality is only available on one platform or the default set of functionality should vary per-platform.

@alexcrichton

This comment has been minimized.

Copy link
Member Author

@alexcrichton alexcrichton commented Jan 20, 2015

cc @huonw

@nox

This comment has been minimized.

Copy link
Contributor

@nox nox commented Jul 10, 2016

Shouldn't this work?

[target.'cfg(not(any(target_os = "android", target_os = "windows")))'.dependencies]
ipc-channel = {git = "https://github.com/servo/ipc-channel"}

[target.'cfg(any(target_os = "android", target_os = "windows"))'.dependencies]
ipc-channel = {git = "https://github.com/servo/ipc-channel", features = ["inprocess"]}
@alexcrichton

This comment has been minimized.

Copy link
Member Author

@alexcrichton alexcrichton commented Jul 11, 2016

@nox in theory yeah that seems like it should work, but today due to the structure of Resolve it doesn't. The entire target-independent resolution graph is created and then only later filtered down to the relevant set of packages. As an artifact of creating Resolve at the beginning it resolves all features, basically with a map from package to list of features. That means that all instances of ipc-channel in your example would have the inprocess feature enabled, regardless of what platform it was on.

I think that's a fixable bug, however, although likely quite invasive as it would require deferring calculation of features to the compilation phase rather than the resolution phase.

nox added a commit to nox/ipc-channel that referenced this issue Jul 12, 2016
bors-servo added a commit to servo/ipc-channel that referenced this issue Jul 12, 2016
Revert "Introduce an inprocess feature"

This reverts commit a1b6926.
See rust-lang/cargo#1197 (comment)
@jethrogb

This comment has been minimized.

Copy link
Contributor

@jethrogb jethrogb commented Nov 5, 2016

Ran into this extremely confusing bug today...

@gyscos

This comment has been minimized.

Copy link

@gyscos gyscos commented Dec 20, 2016

Would this also allow specifying a target-specific features.default array?
Something like:

[target.'cfg(not(target_os = "windows"))'.features]
default = ["general_feature"]

[target.'cfg(target_os = "windows")'.features]
default = ["winonly_replacement"]

I suppose a workaround to get this would be an intermediate crate which depends on the actual crate with target-dependent features, but it doesn't sound very convenient.

@alexcrichton

This comment has been minimized.

Copy link
Member Author

@alexcrichton alexcrichton commented Dec 20, 2016

@gyscos that seems like a nifty and natural way to encode this information! I haven't though too much about the implications of target-specific features, but I don't particularly see any immediate reason to block anything.

@nox

This comment has been minimized.

Copy link
Contributor

@nox nox commented Mar 4, 2017

This isn't enough, I don't want my crate to stop working because someone used no-default-features.

I guess one could use @retep998's trick of enabling a feature programatically from a build.rs script.

@retep998

This comment has been minimized.

Copy link
Member

@retep998 retep998 commented Mar 4, 2017

@nox That enables features in code programmatically. It doesn't let me control dependencies, but for some people just controlling their code might be enough. The reason I even wrote that trick was due to the lack of support for cyclic features. https://github.com/retep998/winapi-rs/blob/dev/build.rs#L193

@philn

This comment has been minimized.

Copy link

@philn philn commented Oct 18, 2017

What's the status of this issue? It would be interesting to use target-specific features in gecko-media (enable pulseaudio only for linux for instance).

@alexcrichton

This comment has been minimized.

Copy link
Member Author

@alexcrichton alexcrichton commented Oct 18, 2017

@philn AFAIK no progress has been made

@praetp

This comment has been minimized.

Copy link

@praetp praetp commented May 3, 2018

Hope we can see progress on this issue...

ferjm added a commit to ferjm/media that referenced this issue Sep 9, 2019
ferjm added a commit to ferjm/media that referenced this issue Sep 9, 2019
@ehuss ehuss self-assigned this Dec 6, 2019
bors added a commit to rust-lang/crates.io that referenced this issue Dec 19, 2019
Disable the background_threads jemallocator feature

It's not supported on macOS :(

![Sad mac icon](https://user-images.githubusercontent.com/193874/70942958-c20d1880-201d-11ea-88bb-4f4188ce0d36.png)

When I try to `cargo run --bin server` on macOS Catalina 10.15.1, I get:

```
$ cargo run --bin server
    Finished dev [unoptimized + debuginfo] target(s) in 0.51s
     Running `target/debug/server`
<jemalloc>: option background_thread currently supports pthread only
memory allocation of 40 bytes failedAbort trap: 6
```

Leave [the upgrade](#1953) but turn off the `background_threads` feature for now. [Someday we might be able to enable features per-target](rust-lang/cargo#1197), but that day is not today.

r? @jtgeibel
glandium added a commit to glandium/git-cinnabar that referenced this issue Feb 15, 2020
Unfortunately, it means we cannot default Windows to statically link anymore,
because of rust-lang/cargo#1197
glandium added a commit to glandium/git-cinnabar that referenced this issue Feb 15, 2020
Unfortunately, it means we cannot default Windows to statically link anymore,
because of rust-lang/cargo#1197
glandium added a commit to glandium/git-cinnabar that referenced this issue Feb 15, 2020
Unfortunately, it means we cannot default Windows to statically link anymore,
because of rust-lang/cargo#1197
glandium added a commit to glandium/git-cinnabar that referenced this issue Feb 15, 2020
Unfortunately, it means we cannot default Windows to statically link anymore,
because of rust-lang/cargo#1197
glandium added a commit to glandium/git-cinnabar that referenced this issue Feb 15, 2020
Unfortunately, it means we cannot default Windows to statically link anymore,
because of rust-lang/cargo#1197
glandium added a commit to glandium/git-cinnabar that referenced this issue Feb 15, 2020
Unfortunately, it means we cannot default Windows to statically link anymore,
because of rust-lang/cargo#1197
glandium added a commit to glandium/git-cinnabar that referenced this issue Feb 15, 2020
Unfortunately, it means we cannot default Windows to statically link anymore,
because of rust-lang/cargo#1197
glandium added a commit to glandium/git-cinnabar that referenced this issue Feb 16, 2020
Unfortunately, it means we cannot default Windows to statically link anymore,
because of rust-lang/cargo#1197
glandium added a commit to glandium/git-cinnabar that referenced this issue Feb 17, 2020
Unfortunately, it means we cannot default Windows to statically link anymore,
because of rust-lang/cargo#1197
glandium added a commit to glandium/git-cinnabar that referenced this issue Feb 18, 2020
Unfortunately, it means we cannot default Windows to statically link anymore,
because of rust-lang/cargo#1197
glandium added a commit to glandium/git-cinnabar that referenced this issue Feb 19, 2020
Unfortunately, it means we cannot default Windows to statically link anymore,
because of rust-lang/cargo#1197
glandium added a commit to glandium/git-cinnabar that referenced this issue Feb 20, 2020
Unfortunately, it means we cannot default Windows to statically link anymore,
because of rust-lang/cargo#1197
@ehuss

This comment has been minimized.

Copy link
Contributor

@ehuss ehuss commented Feb 24, 2020

Target-specific features for dependencies has been implemented and is available as a nightly-only feature on the latest nightly 2020-02-23. See the tracking issue at #7914.

If people following this issue could try it out, and leave your feedback on the tracking issue (#7914), I would appreciate it. Particularly we'd like to know if it helps your project and does it cause any breakage?

I'm going to leave this issue open, for the request of also changing the default features.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.