We've thought from time to time that it'd make sense to have global
features that are "community agreed upon" which can be configured from the
top level without threading everything through, although there isn't
currently a dedicated bug for this.
On Tue, May 31, 2016 at 7:46 AM, Jack Moffitt wro
On Thu, Jun 2, 2016 at 11:20 AM, Manish Goregaokar
wrote:
> It seems like it's still checking the git repo for the feature. Might be
> worth landing your devices changes and proceeding from there.
I've filed a Cargo bug:
https://github.com/rust-lang/cargo/issues/2762
And created a devices PR:
It seems like it's still checking the git repo for the feature. Might be
worth landing your devices changes and proceeding from there.
-Manish Goregaokar
On Thu, Jun 2, 2016 at 12:56 PM, Dirkjan Ochtman wrote:
> On Wed, Jun 1, 2016 at 10:53 AM, Manish Goregaokar
> wrote:
> > It should be net/d
On Wed, Jun 1, 2016 at 10:53 AM, Manish Goregaokar
wrote:
> It should be net/device/bluetooth. For some reason the crate is imported as
> "device" instead of "devices" in net
I'm somehow still running into trouble. Can someone spot the mistake?
djc@dochtman-dev servo $ cat ~/.cargo/config
paths
If the `bluetooth` feature is enabled by default, then you will also need
to pass `--no-default-features` to the `cargo build` command (and then add
back any features that you *do* want). We don't currently have a way to do
this through `mach build` but it would be easy to add by adding a new
argu
It should be net/device/bluetooth. For some reason the crate is imported as
"device" instead of "devices" in net
-Manish Goregaokar
On Wed, Jun 1, 2016 at 1:29 PM, Dirkjan Ochtman wrote:
> On Tue, May 31, 2016 at 4:51 PM, Simon Sapin wrote:
> >> It is possible currently to do `cargo build --fe
On Tue, May 31, 2016 at 4:51 PM, Simon Sapin wrote:
>> 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/devi
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 wrote:
> On 31/05/16 16:40, Manish Goregaokar wrote:
>
>> My ma
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 com
> 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, but IIRC this
> isn't always supposed to work (
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 "dro
> Doing it via Cargo features sounds like the better option to me. I'm fine
> with enabling building Servo without bluetooth support.
+1. We've had environment variable hacks before, and while convenient,
we usually end up regretting and removing them.
jack.
__
On 2016-05-31 10:12 AM, Dirkjan Ochtman wrote:
Hi all,
I'm investigating building a Servo-based headless browser (i.e. get
input events through the network, send PNGs out to the network).
Ideally, I'd like to get it to work on CentOS 6-based servers. Trying
to build server on one of these machin
13 matches
Mail list logo
