Target wasm directly from clang

[tanoxyz]

Maybe this is out of scope.

But I think that make the sokol headers compile without the need of emscripten will make their use easier.

The advantage of emscripten is that generates a lot of glue code between javascript and wasm, but based on the demos of http://schellcode.github.io/webassembly-without-emscripten you can put the javascript on the h/c source files and with some macro magic export that code as string. You only need a minimal index.html that reads de .wasm file and evaluates the functions at load time.

This also comes with side effect advantages, because the macro magic all the comments will be striped from de javascript, and if the javascript function isn't used from the C code it also will be removed.

One big disadvantage is that clang doesn't come with cstdlib for wasm so you can't use any of the standard library functions. Note that with zig you can but comes with other problems.

https://gist.github.com/cmp102/b2f84aeae28f8650ec4090d342d9219c here is a minimal example of this idea.

Maybe make the sokol headers compatible with this kind of wasm loader is useful. But will increase the code needed to bind all the webgl stuff.

I hope this is useful.

[floooh]

Yeah, it's in the back of my head, but very tricky, mainly because of two reasons:

• all the web API Javascript shims (for WebGL, WebAudio, and a lot of smaller ones) would need to be created again and shipped with the sokol headers
• all the Javascript code that's currently inside EM_JS would need to be moved into separate Javascript files, breaking the "single-file" philosophy.

The latest version of the link you posted is WAJIC btw, and it might make sense to support this as an alternative "backend" to Emscripten, it basically does the same thing as the Emscripten SDK though, just with slightly different tools:

https://github.com/schellingb/wajic

This also comes with side effect advantages, because the macro magic all the comments will be striped from de javascript, and if the javascript function isn't used from the C code it also will be removed.

...this is also the case in recent Emscripten SDK versions. All Javascript code (including the code inside EM_JS()) is dead-code-eliminated, and minified in the linker stage. In older Emscripten SDK versions the strings in EM_JS() were duplicated in the WASM blob, but those are now stripped in the linker stage (I think EM_JS is now as efficient as it can get).

[floooh]

PS: specifically for Zig here's a gist that I've been meaning to try out with the pacman.zig project (this uses the Emscripten SDK only for the sysroot and linker):

https://gist.github.com/kripken/58c0e640227fe5bac9e7b30100a2a1d3

[tanoxyz]

Well, the EM_JS functions don't have to go into other files. My idea would be eliminate all the emscripten internal libraries calls and do all in JavaScript using something like "SOKOL__JS(...)" the painful part is bind all the webgl stuff, but until this is done we only need a simple ifdef, if you are using emscripten SOKOL__JS becomes EM_JS if not, becomes the macro from wajic.

If you compile that with clang, all de JavaScript code will be embebed into the .wasm and with a small index.html you can load the wasm, instantiate all de functions and call main.

If you have compiled with emscripten should work in the same way as before.

I'm working on my own platform abstraction library highly based on the sokol headers with the goal of just crosscompile with clang or zig, here is the draft https://gist.github.com/cmp102/fd43e95e09397ce64f601ec3b869f6b6

[floooh]

Ah alright, yes that would work, although having all that unminified Javascript embedded in the WASM isn't great. In Emscripten (and also WAJIC), the strings are only placed temporarily in the compiled blobs until the linker stage, where they are extracted (and removed), placed in a separate JS file and then minified (at least that's the case in Emscripten, don't know if WAJIT does minification).

It's not something I want to commit to at the moment though ;)

What definitely makes sense though is getting rid of any Emscripten specific APIs (basically all the emscripten_* calls and replace those with EM_JS() embeddings). At least that might make the job easier later to disentangle the WASM build from Emscripten features.