Suggestion: Add way to compile only the js wrapper, and not the .wasm

[Taytay]

I am compiling the same .wasm file, but multiple wrappers for different environments (one for the web worker environment, another for the web/node environment). I see that I can tell emcc to only generate the wasm without the wrapper, but I don't see a way to tell it either:
A) Fetch this particular .wasm file at runtime (because WASM_BINARY_FILE is internal only)
B) Only generate the .js wrapper because I've already generated a .wasm file elsewhere.

Am I missing something? Is there a way to do this?

[sbc100]

I don't know of any way to do this no. Why not just build he wasm file multiple times?

I'm also not sure there are any guarantees that if you build for a specific environment it won't effect that wasm file also. I can't think how it would.. but its not inconceivable. Out of interest are the wasm files you are getting bit-for-bit identical?

[Taytay]

Good question - I'll run some tests and see. I made an assumption that they would be. It's not the end of the world, but creating this wasm file for this build (https://github.com/kripken/sql.js/pull/255) takes around 10s, and with all of these permutations, that's going to take a while:

[release, debug] * [web, node, worker ] =
release_web
debug_web
release_node
debug_node
release_worker
debug_worker

[sbc100]

Have you tried using the upstream llvm backend? In this mode your object files are ahead of time compiled so linking your final binary should be a lot faster.

Also, are you rebuilding all the object files for each config or is it just linking that takes 10s?

[Taytay]

@sbc100 : Hey Sam, I don't think my Google-Fu is working that well this morning. I'm trying to understand how to use the LLVM backend, and I didn't find anything straightforward. I see mention of Fastcomp in a few places, but there is also talk of that being the default. Can you please point me to the appropriate place to tell me how to try the upstream LLVM backend?

[Taytay]

And in answer to your question, they are indeed bit-for-bit compatible when I run these two different compilation steps:

emcc --memory-init-file 0 -s RESERVED_FUNCTION_POINTERS=64 -s EXPORTED_FUNCTIONS=@src/exported_functions.json -s EXTRA_EXPORTED_RUNTIME_METHODS=@src/exported_runtime_methods.json -s SINGLE_FILE=0 -s NODEJS_CATCH_EXIT=0 -s INLINING_LIMIT=50 -O3 --closure 1 -s ENVIRONMENT=worker -s WASM=1 -s ALLOW_MEMORY_GROWTH=1 out/sqlite3.bc out/extension-functions.bc --pre-js out/api.js -o out/sql-wasm.js

emcc --memory-init-file 0 -s RESERVED_FUNCTION_POINTERS=64 -s EXPORTED_FUNCTIONS=@src/exported_functions.json -s EXTRA_EXPORTED_RUNTIME_METHODS=@src/exported_runtime_methods.json -s SINGLE_FILE=0 -s NODEJS_CATCH_EXIT=0 -s INLINING_LIMIT=50 -O3 --closure 1 -s WASM=1 -s ALLOW_MEMORY_GROWTH=1 out/sqlite3.bc out/extension-functions.bc --pre-js out/api.js -o dist/sql-wasm.js

Note that the only difference is the -s ENVIRONMENT=worker setting.

Since the wrapper creation is currently done at the same time the wasm file is created, I could imagine a scenario where the emitted wasm was not compatible with the wrapper, or the emitted wasm was debug and the wrapper was release or vice versa. Still, the idea of being able to emit "just" a wrapper pointing to a particular wasm would be helpful for me, but I think I might be in the minority here :)

[sbc100]

If you'd like to create patch for this feature I think it would have good chance of being accepted.

One problem is that the wrapper creation depends on the metadata about the wasm as well as the wasm file itself, so I don't think this is trivial change. Might be easier to just the linker multiple times.

[Taytay]

Cool - thanks @sbc100 .
Could you give me a pointer Hey Sam, to the docs on how to use the LLVM backend so that I can use the fast linker repeatedly?

[sbc100]

To use the llvm backend just update the LLVM in your .emscripten to point to a recent build of llvm. Or if you are on linux you can use ./emsdk install upstream-latest.

[stale]

This issue has been automatically marked as stale because there has been no activity in the past year. It will be closed automatically if no further activity occurs in the next 7 days. Feel free to re-open at any time if this issue is still relevant.