Closed trace-andreason closed 3 months ago
Yeah, there's an issue that the Emscripten compiler cannot automatically find its own system header files. That's why there is this code block in the buildLibSokol() build.zig function:
You basically need to do something similar when compiling your own C code into a library in your build.zig. Off the top of my head, untested:
const emsdk = dep_sokol.builder.dependency("emsdk", .{});
const emsdk_path = emsdk.path("").getPath(b);
const emsdk_sysroot = b.pathJoin(&.{ emsdk_path, "upstream", "emscripten", "cache", "sysroot" });
const include_path = b.pathJoin(&.{ emsdk_sysroot, "include" });
lib.addSystemIncludePath(.{ .path = include_path });
PS: note that sokol_fetch.h is currently not part of the bindings, but maybe you can 'cheat' with Zig's @embedFile
(e.g. instead of loading the texture data via HTTP, just embed it in the WASM blob).
damn, worked like a charm. Yeah, now I need to work out how to get my textures copied over to the web build, or just embed the files like you suggested. Thank you so much for the help!
What is the purpose of sokol_fetch? I assumed that it wasn't part of the bindings because it wasn't necessary, but sounds like that isn't the case. Is it just to provide an abstraction for fitting IO into the event loop in a cross platform way? Am I actually going to need sokol_fetch to load an image without going the embedFile route?
sokol_fetch.h is basically an asynchronous file loader that works both on native platforms (by loading from the filesystem) and web (by loading data via XmlHttpRequest (or at some point in the future, the fetch API).
Other language bindings don't have proper web support yet, so including sokol_fetch.h in the bindings didn't make much sense. With the Zig bindings it might make sense though.
PS:
Yeah, there's an issue that the Emscripten compiler cannot automatically find its own system header files.
What I wrote here is actually incorrect ;)
It's actually the Zig compiler which compiles the C code to WASM of course, so it kinda makes sense that it's necessary to add the path to the Emscripten SDK in order to find the right system headers. I remember that in the past there was a confusion because I had already passed the Emscripten sysroot directory to Zig, and it didn't quite make sense that a separate include directory inside the sysroot had to be passed as well. But AFAIK there is no concept of a 'cross-compilation sysroot' in the Zig build system anymore, I might be wrong though.
I'm working on this repo https://github.com/trace-andreason/zig-learn-opengl-in-sokol where I'm going through the examples in the sokol learn openGL repo https://github.com/zeromake/learnopengl-examples and converting them over to zig. I can't figure out how to get the examples that need image files for textures to build using the emscripten target. Its complaining about not being able to find stdio.h.
I've looked through your other repos, and I see that files are never loaded due to issues with zig and wasm. I'm new to basically everything involved here so I'm not sure if there is anything I can do to get this working. I've posted the full verbose build output below.
I guess my question is, is loading images for textures just not possible right now? Should I just move on? Thanks in advanced for the help!