Feature dependencies

[JanLikar]

Fix #1570 based on commits from PR #2056 by @tsurai to master.

test_cargo_test::selective_test_optional_dep fails with features cannot be modified when the main package is not being built. Any ideas?

[rust-highfive]

r? @huonw

(rust_highfive has picked a reviewer for you, use r? to override)

[JanLikar]

r? @alexcrichton

[alexcrichton]

Could this change to returning Option<&[T]> instead of Option<&Vec<T>>? (generally a little more ergonomic)

[alexcrichton]

Thanks @JanLikar! Can you also add some tests involving example and test targets with feature dependencies as well?

[alexcrichton]

I'm also wondering if we want to rename this key in the manifest because features kinda says to me "if you're building this target, enable these features". That's at least the interpretation of the features key in dependencies. This leads me to a few thoughts:

• Perhaps something that invokes thoughts of "this requires these features to be enabled" or something like that.
• We may want to make sure that cargo build --bin foo has a good error message. Right now I think the error message says that foo doesn't exist, but it'll just have a feature dependency in this case.
• Either that, or perhaps we could say cargo build --bin foo activates the features required by foo because it was explicitly requested. I'd probably prefer to not take this route though...

Thoughts?

[JanLikar]

1. Well, I don't think the features key is a particularly bad idea. Something like requires or required-features could also work, but I'm not sure.
2. I think cargo build --bin foo would be friendlier if it would automatically enable required features, but it would create confusion with beginners, as in "cargo run --bin foo works, but cargo build doesn't produce the foo binary!" Automatic enabling can also be painlessly added in the future...

[alexcrichton]

Ah and of course cc @rust-lang/tools, surely more opinions!

[brson]

No strong opinion but the docs should be updated somewhere.

[alexcrichton]

It's perhaps most advantageous to take the conservative route for now and have cargo build --bin foo fail if foo requires some features (but providing a nicer error message).

[alexcrichton]

Ok, had a chance to chat with @wycats about this, and the conclusion was:

• Let's call this required-features to distinguish from the features key
• Let's not implicitly enable features for now, but still ensure that the error message is of sufficiently high quality to prevent too much confusion

[mitchmindtree]

Just came across #1570 which led me here - just thought I'd give this a big +1! Very keen to use this required-features key in conrod.

[JanLikar]

@mitchmindtree and others, I didn't find enough time to actually complete this, but I think I will be able to in the next couple of days.

[alexcrichton]

Closing due to inactivity, but feel free to resubmit with fixes!

[branan]

I ran into wanting this over the weekend, so I've started looking at taking it over and fixing up the comments. I have never touched the cargo source before, so I might give up, but so far the tweaks have been easy enough

[alexcrichton]

Awesome! Let me know if you need any help @branan!