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

Use euclid 0.19.3+ exported from webrender_api. #3326

Merged
merged 1 commit into from Nov 19, 2018
Merged
Changes from all commits
Commits
File filter...
Filter file types
Jump to…
Jump to file
Failed to load files.

Always

Just for now

Use euclid 0.19.3+ exported from webrender_api.

  • Loading branch information
nical committed Nov 19, 2018
commit 325d11b3b1fb09151b6ef4fddf4b5cf4c34410b3

Some generated files are not rendered by default. Learn more.

@@ -25,7 +25,6 @@ bincode = "1.0"
bitflags = "1.0"
byteorder = "1.0"
cfg-if = "0.1.2"
euclid = "0.19"
fxhash = "0.2.1"
gleam = "0.6.3"
image = { optional = true, version = "0.20" }
@@ -159,7 +159,6 @@ extern crate dwrote;
extern crate app_units;
extern crate bincode;
extern crate byteorder;
extern crate euclid;
extern crate fxhash;
extern crate gleam;
extern crate num_traits;
@@ -202,4 +201,5 @@ pub use renderer::{RendererStats, SceneBuilderHooks, ThreadListener, ShaderPreca
pub use renderer::MAX_VERTEX_TEXTURE_WIDTH;
pub use shade::{Shaders, WrShaders};
pub use webrender_api as api;
pub use resource_cache::intersect_for_tile;
pub use webrender_api::euclid;

This comment has been minimized.

@kvark

kvark Nov 19, 2018

Member

is this meant to be pub?

This comment has been minimized.

@nical

nical Nov 19, 2018

Author Collaborator

yeah, I can't think of any reason to not make it public since users of webrender need to keep in sync with webrender's version of euclid. This way it's easier to just use webrender::euclid or webrender_api::euclid (depending on the situation) and not have to worry about having the right version the Cargo.toml.

In my opinion we should do this with all of the dependencies that are both in webrender and webrender_api, it's simpler to manage.

This comment has been minimized.

@kvark

kvark Nov 19, 2018

Member

I don't think it's possible to work with webrender but not link to webrender_api. Since the latter already exposes euclid, it would be more strict to just keep it the only crate that re-exports dependencies.

This comment has been minimized.

@nical

nical Nov 19, 2018

Author Collaborator

I'm not sure what would be the advantage from being stricter here. For all consumers of WebRender except servo, the webrender crate is the only dependency and the api is treated as module of it. It's rather common to expose public dependencies at the root of the crate. I wouldn't lose sleep over having to look for euclid and other dependencies in webrender::api rather than the root if you feel strongly about it but I'm curious about what the pros of that would be.

This comment has been minimized.

@kvark

kvark Nov 19, 2018

Member

ah, right, they access it through webrender::api. Ok, that's fine then

pub use resource_cache::intersect_for_tile;

This comment has been minimized.

@kvark

kvark Nov 19, 2018

Member

nit: newline

@@ -18,7 +18,7 @@ bincode = "1.0"
bitflags = "1.0"
byteorder = "1.2.1"
ipc-channel = {version = "0.11.0", optional = true}
euclid = { version = "0.19", features = ["serde"] }
euclid = { version = "0.19.3", features = ["serde"] }
serde = { version = "=1.0.80", features = ["rc"] }
serde_derive = { version = "=1.0.80", features = ["deserialize_in_place"] }
serde_bytes = "0.10"
@@ -27,7 +27,7 @@ extern crate core_foundation;
extern crate core_graphics;
#[cfg(target_os = "windows")]
extern crate dwrote;
extern crate euclid;
pub extern crate euclid;
#[cfg(feature = "ipc")]
extern crate ipc_channel;
extern crate serde;
ProTip! Use n and p to navigate between commits in a pull request.
You can’t perform that action at this time.