Oh, interesting. I have had strange errors when not fully specifying the features but the reason might have been something else.
We should just do that, then, agreed. -Manish Goregaokar On Tue, May 31, 2016 at 8:21 PM, Simon Sapin <simon.sa...@exyr.org> wrote: > On 31/05/16 16:40, Manish Goregaokar wrote: > >> My main issue with cargo features is that they would pollute all the >> Cargo.tomls in the dependency tree between servo and devices, and if >> another dependency is added (even amongst these crates) it would have to >> be >> added, or else we may get confusing compile errors. >> >> It would be nice if you can "drop in" features from above without >> requiring >> daisy chaining, but AFAICT that's not always doable. >> >> It is possible currently to do `cargo build --features >> net/devices/nameoffeature` without polluting cargo.tomls, >> > > > I think we can have something like this in components/servo/Cargo.toml : > > [features] > no-bluetooth = ["net/devices/no-bluetooth"] > > > but IIRC this >> isn't always supposed to work (since all the other dependency paths do not >> have it enabled). If this turns out to be working reliably I'd prefer to >> do >> this, though it may unexpectedly break in the future. >> > > Why isn’t this supposed to work? Based on conversations with Alex, Cargo > by design builds a crate with the union of all requested features. There is > no need for all dependents to specify the same set of features and this > isn’t an accident. > > -- > Simon Sapin > > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
