WebAssembly support

[migueldeicaza]

We would like to make it so that developers that want to use SwiftGodot can target Wasm, a popular platform for Godot to be deployed to.

This issue is intended to keep track of the various findings, it will be edited as we find out more information, so this text will change.

Here is roughly where we stand right now:

1. Godot seems to use the Emscripten ABI
2. Swift/Wasm seems to use the WASI API, and these are different
3. We use a lot of Macros, and SwiftWasm does not currently support it, but there is a patch coming soon Support macros when cross-compiling swiftlang/swift-package-manager#7118

While SwiftWASM only supports the executable target, it seems that in the Wasm world, even regular executables can be treated as libraries, so we would need to figure out a way of stitching those together. One possible problem with this approach is that currently we might assume that the extension and Godot share the same memory address space so this could be a problem.

Things that we could also consider:

1. Compiling Godot as a library
2. Have our build system link Godot with the SwiftGodot target, like SwiftGodotKit in a way.

Discussion links

Initial discussion on using SwiftWasm for Godot:
https://discord.com/channels/780838335798706197/802944960881098752/1208500336671854662

Recent discussion:

https://discord.com/channels/780838335798706197/790246707648135229/1225627478471610398

Resoures

Setting up Swift for WASM: https://book.swiftwasm.org/getting-started/setup.html

SwiftGodot without Macros dependency, useful to prototype, courtesy of @PadraigK: https://github.com/PadraigK/SwiftGodotLite/tree/main

[migueldeicaza]

There are a few updates shared on Slack.

1. The ABI between Godot and Swift was sorted out, the details of how are not clear to me yet

2. There is some discussion on how this got started using --triple wasm32-unknown-none-wasm and https://github.com/apple/swift-for-wasm-examples

3. Talk on Swift for WASM that might be relevant: https://youtu.be/cX5pITN0uFM?si=G7yNZL-HCP5WPbcJ

4. This comment might be a correction over our previous assumptions:

swift doesn’t use the WASI api if you don’t ask it to. You can specify either --triple wasm32-unknown-none-wasm which works with emscripten ( I have linked these and ran them with a godot game ), or you can target the WASI api with the wasi triple

[migueldeicaza]

This command line will build a file that can be linked with Godot Wasm:

swiftc -Osize -Xcc -fdeclspec -target wasm32-unknown-none-wasm -enable-experimental-feature Extern -enable-experimental-feature Embedded -wmo -c -Xlinker --no-entry -Xclang-linker -nostdlib -parse-as-library HelloWorld.swift -o HelloWorld.wasm

From @jordo

What does this all do? 1 - targets the wasm abi, 2 - enables Extern and Embedded. afaict you can decorate functions now and the symbols export and link properly. 3 - enable whole module optimization. 4 - Bunch of linker flags. mostly to tell the linker not to build an entry point and tell it to build as a library symbol otherwise it sticks a main in for you...

You can inspect the wasm module now with tools like wasm-tools. You don't have tools like nm but there are all equivalents there. You can see the symbol tables, etc.
You can then use emscriptens 'load time dynamic linking' to build a single wasm. You can read about this here: https://emscripten.org/docs/compiling/Dynamic-Linking.html but ultimately, you can link the wasm module into your main library at build time and deliver a single wasm payload.