Not-Nik / raylib-zig

Manually tweaked, auto-generated raylib bindings for zig. https://github.com/raysan5/raylib
MIT License
473 stars 101 forks source link

Add web build support using emscripten #52

Closed bluesillybeard closed 11 months ago

bluesillybeard commented 11 months ago

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.

Not-Nik commented 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:

Additionally I'll add your getModule fix separately so the commit history is more clear.

Not-Nik commented 11 months ago

Don't worry about the merge conflict, we'll cross that bridge when we come to it

bluesillybeard commented 11 months ago

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.

bluesillybeard commented 11 months ago

the webExport function is used in the project_setup.sh

bluesillybeard commented 11 months ago

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.

Not-Nik commented 11 months ago

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

Not-Nik commented 11 months ago

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.

bluesillybeard commented 11 months ago

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.

bluesillybeard commented 11 months ago

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.

Not-Nik commented 11 months ago

Looks good to me, if this is ready I'll merge it.

bluesillybeard commented 11 months ago

I think it's pretty much ready to merge, so go ahead if you think so too.