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

Allow arbitrary Horn clauses for inter-feature dependencies. #6789

Open
hvenev opened this issue Mar 28, 2019 · 2 comments
Open

Allow arbitrary Horn clauses for inter-feature dependencies. #6789

hvenev opened this issue Mar 28, 2019 · 2 comments
Labels
A-features Area: features — conditional compilation C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage.

Comments

@hvenev
Copy link

hvenev commented Mar 28, 2019

Sometimes it makes sense to enable feature Z if both features Y and feature Z are enabled. Simple example: #6658

[dependencies]
krate = { optional = true, version = "1.2.3" }

[features]
bar = []
foo = [ "krate" ]
"foo+bar" = [ "krate/bar" ]

Another example pops up in native library bindings:

name = "libB-sys"

[dependencies]
libA-sys = { optional = true, version = "4.5.6" } # libA is used by libB to do featX

[features]
vendored = [] # Build the bundled copy of the library instead of using the system one
featX = []
"vendored+featX" = "libA-sys"

It may also make sense to have clauses where resolution fails:

[features]
"do-it-this-way+do-it-that-way" = false

Note that this does not permit requirements of the form "featX or featY must be enabled". The naive algorithm that only enables a feature when all prerequisites are enabled still works (https://www.doc.ic.ac.uk/~rak/papers/kowalski-van_emden.pdf, the "model intersection property")

@hvenev hvenev added the C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` label Mar 28, 2019
@ehuss ehuss added the A-features Area: features — conditional compilation label Apr 4, 2019
@epage
Copy link
Contributor

epage commented Oct 31, 2023

"do-it-this-way+do-it-that-way" = false

This runs afoul of feature unification. We have #2980 discussing the use cases further with https://internals.rust-lang.org/t/pre-rfc-mutually-excusive-global-features/19618 as a concrete proposal.

@epage
Copy link
Contributor

epage commented Oct 31, 2023

[dependencies]
krate = { optional = true, version = "1.2.3" }

[features]
bar = []
foo = [ "krate" ]
"foo+bar" = [ "krate/bar" ]

I believe this would now be solved by

[dependencies]
krate = { optional = true, version = "1.2.3" }

[features]
bar = ["krate?/bar"]
foo = [ "krate" ]

See https://doc.rust-lang.org/cargo/reference/features.html#dependency-features for more on ? (weak features)

@epage epage added the S-triage Status: This issue is waiting on initial triage. label Oct 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-features Area: features — conditional compilation C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

3 participants