[build][Zig] 0.17 migration

[miker2049]

Zig 0.17 is not out yet, but it (supposedly) will be soon. There was recently some breaking changes to the build system, causing nightly zig to not work with raylib's build.zig.

Because the aforementioned changes are not in a major release yet, this probably should not be merged yet. But it doesn't seem like there will be many further breaking changes before the major release, so this can be considered a tentative PR for when it happens. One further consideration here is that this branch uses an unmerged branch of zemscripten which updates it for 0.17. So, hopefully that can be merged before this should be!

[raysan5]

@michaelfiber, @Not-Nik, @HaxSam, @shreyassanthu77, @pamarcos, @jn-jairo, @jirizverina, @BrunoDG, @maiconpintoabreu, @beppvis Please, could you take a look to this PR?

NOTE: I'm pinging all of you in my list of Zig build system maintainers, if any of you doesn't want to be pinged for this kind of issues, just let me know and I'll take you out of the maintainers list.

[Not-Nik]

Besides the hash mismatch this compiles cleanly. Since I believe our policy is to keep up with master when required, r+

[Not-Nik]

I'm seeing a hash mismatch for this package with the patch on 0.17.0-dev.1158+1d1193aa7, where it fetches N-V-__8AALBDi159DH5nlv03KX8rG4GFfY8m-GWnFC9DSQL2. Either I'm being MITMed or the hash actually changed (through Zig or emsdk itself). Could someone verify (on a clean build/system).

[jn-jairo]

I ran it on a clean build, cleaned all caches, with both the most recent zig version available at the moment 0.17.0-dev.1417+20befa4e6 as well the minimum version set in this PR 0.17.0-dev.1158+1d1193aa7 and I did not get any hash error, the hash downloaded is the N-V-__8AAJl1DwBezhYo_VE6f53mPVm00R-Fk28NPW7P14EQ.

[Not-Nik]

Cleaned up all my cached files as well, and the mismatch is gone. Strange it occurred at all though..

[jn-jairo]

The new emcc is not building the files.

This is with the new code

And this is with the old code from raylib master

As the note about the install path says, this code is using the wrong path to run, trying to get it from the zig-out/<filename> instead of the zig-out/web/<module>/<filename>.

An old version of the build.zig was duplicating the installed files at the root zig-out/<filename> but it was already fixed, you must have a dirty install with old files already built, so you are not running from files built with the new code.

The only error I get is

textures_bunnymark
└─ run dependency
   └─ install generated/
      └─ run dependency (textures_bunnymark) w
shared:INFO: (Emscripten: Running sanity checks)
failed command: /mnt/hd/projects/code/raylib-pr/zig-pkg/N-V-__8AAJl1DwBezhYo_VE6f53mPVm00R-Fk28NPW7P14EQ/upstream/emscripten/emcc.py -O3 -sASYNCIFY -sTOTAL_MEMORY=134217728 -sFORCE_FILESYSTEM=1 -sMALLOC=emmalloc -sUSE_GLFW=3 -sEXPORTED_RUNTIME_METHODS=ccall ./.zig-cache/o/d879f429e89efb52350f0b58e42915cc/libtextures_bunnymark.a ./.zig-cache/o/667685bf2c596541996f084e5ef321b6/libraylib.a -o ./.zig-cache/o/a995d324b9810090a6b25a0ae46d4312/textures_bunnymark --shell-file /mnt/hd/projects/code/raylib-pr/src/shell.html

I am using Kubuntu 24.04.4 LTS and besides the web build, the desktop build is working on my machine.

Tested with the most recent zig version available at the moment 0.17.0-dev.1417+20befa4e6 as well the minimum version set in this PR 0.17.0-dev.1158+1d1193aa7.

[jn-jairo]

Wrong path, it should be the one from install_dir web/<module>/<filename> so install_dir.custom instead of filename should work.

[miker2049]

f1dc836

[jn-jairo]

Not what you changed, but this line should be removed, it forces to run the emcc_step for every example even when we are not building the examples, the emcc_step will run anyway when building one or more examples because of the run_step and all step.

[miker2049]

Fixed in 23e73da

[miker2049]

I realized that resource asset files were not working for the emscripten examples. It is blocked by this issue with upstream zemscripten, where the build file there does not actually support virtual paths.

[jn-jairo]

I realized that resource asset files were not working for the emscripten examples. It is blocked by this issue with upstream zemscripten, where the build file there does not actually support virtual paths.

Ok, let's see what we get here, zig-gamedev/zemscripten didn't merge the zig 0.17 PR, so you changed the repo here to point to the PR branch at Yinameah/zemscripten and also there is a bug with preload_paths not using the ResourceFile.get() they added.

And as you said it is temporary while they don't merge it.

One further consideration here is that this branch uses an unmerged branch of zemscripten which updates it for 0.17. So, hopefully that can be merged before this should be!

So, we are waiting for the zig-gamedev team to do something about the zig upgrade and the preload_paths bug.

The last response from zig-gamedev team was a month ago at the zig 0.17 issue where they said:

Thanks for reaching out. It's difficult to stay on top of maintenance churn of all the zig-gamedev libraries so any help is very welcome. If you want to discuss anything in a more informal forum please feel free to join us on Discord https://discord.gg/JrYcW5sUD

And by looking at other repos from zig-gamedev they don't upgrade zig to a new version until way later. Like the zaudio upgrade to zig 0.16 that got merged just last week.

So, will we wait for zig-gamedev to fix things up or what?

[jn-jairo]

From here it should be enough, but the zemscripten is bugged anyway, maybe we will need to change something more here later.

[jn-jairo]

Besides the preload_paths bug on zemscripten this part is not working, the new src_path is a std.Build.LazyPath, this cast is not filling it up. Here is what I did:

            const ResourceDesc = struct {
                src_path: []const u8,
                virtual_path: []const u8,
            };

            const EmccExamplesPreloadMap = std.StaticStringMap([]const ResourceDesc);
            const EmccExamplesPreloadKV = struct { []const u8, []const ResourceDesc };
            const emcc_examples_preloads: []const EmccExamplesPreloadKV = @import("examples/example_resources.zon");
            const emcc_examples_preloads_map = EmccExamplesPreloadMap.initComptime(emcc_examples_preloads);

            const preload_paths_: []const ResourceDesc = emcc_examples_preloads_map.get(filename) orelse &.{};

            var preload_paths = std.ArrayList(emsdk.zemscripten.ResourceFile).empty;
            defer preload_paths.deinit(b.allocator);

            for (preload_paths_) |preload_path| {
                try preload_paths.append(b.allocator, .{
                    .src_path = b.path(preload_path.src_path),
                    .virtual_path = preload_path.virtual_path,
                });
            }

            const emcc_step = emsdk.emccStep(b, raylib, wasm, .{
                .optimize = optimize,
                .flags = emcc_flags,
                .settings = emcc_settings,
                .preload_paths = preload_paths.items,
                .shell_file_path = b.path("src/shell.html"),
                .install_dir = install_dir,
                .out_file_name = wasm.name,
            });

also there is a bug with preload_paths not using the ResourceFile.get() they added.

I tried to fix it using your proposed solution emcc.addArg(path.get(b)) but turns out the whole ResourceFile.get() is wrong, as it was never used looks like zig never bothered to validate this function, so the self.src_path.path(b, "") it is using just returns another LazyPath instead of a string, but the function needs a string. This is from a commit after the one locked in the master raylib so that is why it works now in raylib, after they changed to that ResourceFile things didn't work anymore, but they didn't realize 🙄.

This hole is deeper than we thought.

[jn-jairo]

I realized that resource asset files were not working for the emscripten examples. It is blocked by this issue with upstream zemscripten, where the build file there does not actually support virtual paths.

I fixed it in my fork try it with the other changes I proposed in the review.

[maiconpintoabreu]

My 2 cents here, I do not agree to keep it updated with zig master as we never had a zig release without breaking changes anyway.

[raysan5]

As mentioned, we should probably wait until a more stable state bfore considering merging it...

[jn-jairo]

For my personal projects I rather use the zig stable version, but I like to use raylib master to keep updated with the fixes and new features, so I vote to wait until zig 0.17 is released and the dependencies are upgraded to it, but it's good to have the PR ready for it.