Cool, thanks for the pointers. I think I'll be investigating abandoning
Rust for Nim because of its better C interop, so it looks like I can use
these functions/interfaces more directly.
Assuming I'm building a nicer C-style interface between not-so-nice
lower-level C and not-so-nice-for-its-own-reasons JS, I'm assuming the
best strategy is modeling data with C-style structs, and modeling my
wrapper functions to accept int32s representing pointers to those structs?
If so, how should I go from pointers to JS objects? Or should I just
treat the pointers as opaque from JS's perspective, write functions to
access their data, then wrap those functions into JS getters? The JS
side of this API is mostly read, with mutations happening by passing
data to the C/Nim API, so opaqueness/getters would probably work if needed.
Thanks for the help.
On 9/23/18 1:33 PM, Alon Zakai wrote:
In emscripten, for simple C APIs you can just use the emscripten.h macro
#define EMSCRIPTEN_KEEPALIVE __attribute__((used)) __attribute__
((visibility ("default")))
If rust lets you define those LLVM attributes somehow, then just
applying those to a function will export it so JS can call it.
However, that doesn't handle string conversions etc., which you can
use ccall/cwrap for. With cwrap you need to declare the functions you
are binding, but it automates all the conversions etc.
For C++ you can also use embind and the WebIDL binder, which automate
even more conversions, emulating C++ objects as JS objects, etc., but
for C you probably don't need those.
Overall it does seem like most Rust interest these days is in
wasm32-unknown-unknown, as they're writing new Rust for JS purposes,
as opposed to what you're doing. I think both use cases are important
though - actually as Rust becomes more common in native development, I
think porting Rust + C combinations will become more important.
On 9/22/18, Nolan Darilek <[email protected]> wrote:
The Rust wasm community seems to prefer wasm32-unknown-unknown these
days. Unfortunately, my use case needs C libraries that will never be
rewritten. I have a fairly small API surface that I'm calling from Yew
(Rust front-end framework) but I'm starting to think I'd be better
served by trying to export that API surface to JS and switching the UI
to a more traditional framework. Is this site still a good reference for
how to do this?
https://hoverbear.org/2017/04/06/the-path-to-rust-on-the-web/
Specifically, it creates a C library wrapping the exported Rust
functions, then an empty `main()`. Given how fast these ecosystems move,
I was wondering if any of this work could be automated? wasm-bindgen is
for wasm32-unknown-unknown if I understand correctly, but I thought I'd
check that assumption.
Are there any current examples of someone building JS modules using Rust
and Emscripten? Or has everyone in the Rust community switched
exclusively to wasm32-unknown-unknown?
Thanks.
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"emscripten-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.