Closed bluesillybeard closed 11 months ago
Hey there, first of all thank you very much for your efforts, it looks great so far. I do have a few notes though:
zig build webexport --sysroot [path to emsdk]/upstream/emscripten
, but there is no webexport step. Building with zig build <example name> -Dtarget=wasm32-emscripten --sysroot [path to emsdk]/upstream/emscripten
worked great for me.updateTargetForWeb
shenanigans on my MacBookwebExport
function seems unused?Additionally I'll add your getModule
fix separately so the commit history is more clear.
Don't worry about the merge conflict, we'll cross that bridge when we come to it
Yeah, I still have some work to do in order to make it work more intuitively. I made it work based on the target for the examples, and webexport for the project but I think it would be best to build based on the target for both scenarios.
the webExport function is used in the project_setup.sh
updateTargetForWeb
seems to not be required in some examples, but is required in others. The reason it's required is in the zig standard library std/c.zig
is missing fd_t
which causes an error.
I've submitted an issue to the Zig developers so they can fix it in the meantime.
Then I suggest we keep the updateTargetForWeb
until that is fixed in a stable release of Zig.
I will convert this PR into a draft; do convert it back once you feel it is ready for review
I'm confused about the entry point. Couldn't we define the main function in Zig as an extern function with the C ABI? We'd still build a library, but not use C as an intermediary.
Try to make the main method extern, and you'll get an error: return type 'anyerror!void' not allowed in function with calling convention 'C'
Removing anyerror!
builds fine, but emscripten doesn't treat it as an entry point since it expects it to return a c_int
, which the main method isn't allowed to do in zig. I also don't want to rely on the exact type of main that someones project uses. (which the web build currently does, I'll have to find a way around that)
The intermediate C file isn't really a big deal anyway, since it's hidden and it all gets linked together nicely.
I think a bigger concern is the web_emscripten_entry_point.zig
thing, since adding files to the source is really weird.
I did some more testing an apparently I've been wrong about emscripten's ability to find entry points this entire time. It's able to find zig's main method no matter what the function signature is, and errors even work properly.
I'm not sure if something changed since I last tested, or if I just missed something obvious, but either way I'm glad I found out because it means I can remove a lot of the hackiness here.
Looks good to me, if this is ready I'll merge it.
I think it's pretty much ready to merge, so go ahead if you think so too.
I added web support to this project using emscripten. It probably only works on Linux at the moment, I haven't tested it on any other OS.
The changes in the readme file should make it clear what the changes entail.
Side note, this is my first "real" project with Zig, and as such my experience with it is quite limited.
It's probably worth noting that I am using Zig version 0.11.0, and the project uses of a lot of tricks to make it work.