WebAssembly Build Support
Closed this issue · 5 comments
Hey, I was trying to build my crate (tokei) which depends deep down on memmap, however currently memmap2's MmapInner currently doesn't compile on WebAssembly platforms. Obviously memory maps don't work on WebAssembly, but it would be nice if it still compiled, but failed at runtime, like std's File.
It was discussed already here: #10
Basically my point was the the caller should omit memmap dependency on their side. Using feature flags.
std is kinda an exception here and I'm not sure what is the best solution.
Basically my point was the the caller should omit memmap dependency on their side.
As someone who doesn't directly depend on memmap2, that's not really a workable solution. I'll also say that not having build support for these platforms, I'm far likely to move away from any dependency that uses memmap2 entirely, than I am to go change my dependency's to cfg it out.
std is kinda an exception here and I'm not sure what is the best solution.
If std is the exception (I don't think it is, both windows, and winapi compile on Linux just fine despite their APIs having zero support for it), then it is the exception that proves the rule, that people expect people expect crates to be cross-compiliation friendly even when there isn't run-time feature support.
people expect crates to be cross-compiliation friendly even when there isn't run-time feature support
Is it stated/specified somewhere? I don't know many crates like this, so I don't know what is the default behaviour here.
Overall, I guess we can simply merge #10 and that's it.
Is it stated/specified somewhere? I don't know many crates like this, so I don't know what is the default behaviour here.
No, it's not an explicit requirement anywhere, but I believe it is an implicit expectation that has built up around Rust crates, following the example of crates like std, and the ease at which you can build and test for other platforms in Rust. I would say generally that most platform specific crates I've encountered in the wild include some amount of stub code for others platforms that users wanted to compile it for.
Aside from the two I already mentioned, other examples of this include num_cpus and libc where the platform details are entirely isolated inside the crate. Even though there's no way to query the CPU or access libc on WebAssembly, you can still compile and use both in WASM.
Thank you for fixing this!