Use "parallel" feature flag #353
Conversation
|
Hm, it still doesn't build when referenced in my project via Anyway, I feel like there's some cleanup to be done in features in Cargo.toml here. I've added |
Cargo.toml
Outdated
| mopa = "0.2" | ||
| shred = "0.6.0" | ||
| shrev = "0.8.0" | ||
| shred-derive = "0.4" |
There was a problem hiding this comment.
I think you accidentally deleted this line.
|
Also, maybe we can add a Travis job to ensure Specs builds for wasm32 in the future. |
to control inclusion of functionality requiring multithreading.
|
Note - I'd still like to check what is the cause of the build problem in my project, whether it requires some attention in specs Cargo.toml or not. Hadn't got time for this lately though ... |
|
OK, it was just missing |
| @@ -163,6 +168,7 @@ pub trait Join { | |||
| /// The purpose of the `ParJoin` trait is to provide a way | |||
| /// to access multiple storages in parallel at the same time with | |||
| /// the merged bit set. | |||
| #[cfg(feature = "parallel")] | |||
There was a problem hiding this comment.
Meh, this isn't really ideal. One should be able to compile just the same code for wasm, but this disallows ParJoin. Instead we'd need a fallback for it. But I'm not sure if we can use rayon at all on wasm :(
There was a problem hiding this comment.
It seems that rayon should build with wasm (rayon-rs/rayon#503), but as wasm doesn't support threads it just panics when using it.
There was a problem hiding this comment.
Heh, what's the point of being able to compile something only for it to blow up later? I thought this behaviour of wasm32-unknown-unknown target is something that's just done so that it can be shipped earlier. Anyhow, I can change it if you wish
There was a problem hiding this comment.
Unless the fallback would be to define ParJoin as Join?
There was a problem hiding this comment.
I wasn't implying we should use it, but just providing info.
There was a problem hiding this comment.
Heh, what's the point of being able to compile something only for it to blow up later?
No, the point is it shouldn't fail but fall back to sequential joining. The problem with "defining ParJoin as Join" is that ParJoin has a different (rayon) API.
|
I'm planning on getting out a new Specs version soon, is anybody still interested in fixing this? It's not really a priority for me right now, although I'd like to target wasm in the future. |
How to fix this issue
|
|
Closing due to inactivity. |
This allows it to be built for targets such as wasm32
This change is