|
Hi all! I have a very basic 60fps project for wasm: // main.rs
#[cfg(target_arch = "wasm32")]
use wasm_bindgen::prelude::*;
sixtyfps::include_modules!();
#[cfg_attr(target_arch = "wasm32", wasm_bindgen(start))]
pub fn main() {
// Better debug suggestions on wasm targets
#[cfg(all(debug_assertions, target_arch = "wasm32"))]
console_error_panic_hook::set_once();
let main = Main::new();
main.run();
}# Cargo.toml
name = "my-package"
version = "0.1.0"
edition = "2021"
[dependencies]
sixtyfps = "0.1.5"
[build-dependencies]
sixtyfps-build = "0.1.5"
[lib]
crate-type = ["cdylib"]
path = "src/main.rs"
[target.'cfg(target_arch = "wasm32")'.dependencies]
wasm-bindgen = { version = "0.2" }
web-sys = { version = "0.3", features = ["console"] }
console_error_panic_hook = "0.1.5"That is failing with the following error: When I run I just find it so strange that a sixtyfps library is erroring on a non-exhaustive match. I imagine one reason that this can be is differing versions, but I don't see how that could come up with Cargo's version resolution. I can attach my Cargo.lock if necessary. So... Is this an issue? Or, am I just doing something wrong? |
Answered by
tronical
Jan 12, 2022
Replies: 2 comments 3 replies
|
That looks like an issue where something activates the fs feature in fontdb. Can you try to paste the output of `cargo tree -e features‘ here? |
3 replies
|
This can happen as soon as the fontdb crate gets loaded trough another crate with different feature. |
|
You're right, that seems the easiest fix. Since we control what's fed into the fontdb instance, such a variant is And who knows, maybe there'll be some virtual file system support for wasm in the future - so perhaps the feature set of fontdb is ok still. |
|
Here's the output of |
|
hi @bobbbay! I can reproduce the issue now. What's happening is that the compiler pulls in resvg, which in turn also pulls in the fontdb crate and enables the file system access feature of the crate. The SixtyFPS compiler is built for your host architecture and the core library and the GL renderer (that's the one that's failing to compile) is built for wasm32-unknown-unknown (by wasm-pack). There are two ways that the cargo dependency resolver deals with this cross-compilation scenario where the fontdb crate is needed by two different builds with different features: (1) When using (2) When using There are three solutions for this: (1) Change your |
0 replies
Answer selected by
tronical
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
hi @bobbbay! I can reproduce the issue now. What's happening is that the compiler pulls in resvg, which in turn also pulls in the fontdb crate and enables the file system access feature of the crate. The SixtyFPS compiler is built for your host architecture and the core library and the GL renderer (that's the one that's failing to compile) is built for wasm32-unknown-unknown (by wasm-pack).
There are two ways that the cargo dependency resolver deals with this cross-compilation scenario where the fontdb crate is needed by two different builds with different features:
(1) When using
edition = "2018"inCargo.toml, the dependency resolver will merge all the features, regardless of the target…