[build] Zig emscripten build broken?

[fjebaker]

• I tested it on latest raylib version from master branch
• I checked there is no similar issue already reported
• I checked the documentation on the wiki
• My code has no errors or misuse of raylib

Issue description

I think #3983 broke the Zig 0.12.0 build. If I pass --sysroot with an absolute path I now get

thread 637865 panic: sub_path is expected to be relative to the build root, but was this absolute path: '/home/lilith/Developer/emsdk/upstream/emscripten/cache/sysroot/include'. It is best avoid absolute paths, but if you must, it is supported by LazyPath.cwd_relative

If I pass --sysroot with relative paths

thread 637149 panic: reached unreachable code
/home/lilith/.zigup/cache/0.12.0/files/lib/std/debug.zig:403:14: 0x10b5bfd in assert (build)
    if (!ok) unreachable; // assertion failure
             ^
/home/lilith/.zigup/cache/0.12.0/files/lib/std/fs.zig:280:11: 0x10f0b3a in openDirAbsolute (build)
    assert(path.isAbsolute(absolute_path));
          ^

due to the std.fs.openAbsoluteDir verifying that a path is absolute or not. I think the changes in #3983 are well intended but are maybe too soon. Upgrading to Zig 0.13.0 when it is released will likely require more work than just changing one line...

I have a commit in a fork I am happy to PR that just reverts the change in #3983. I have tested it and it seems to work fine.

Edit: to suggest a compromise, one could also use something other than openAbsoluteDir to keep some version compat with newer 0.13.0-dev releases.

Environment

Cloned master branch and built with Zig version 0.12.0 with

zig build -Dtarget=wasm32-emscripten --sysroot "/home/lilith/Developer/emsdk/upstream/emscripten"

[raysan5]

@fjebaker Thanks for reporting! Probably @CosmicBagel should comment on this issue.

[dylanlangston]

I'm also seeing this issue in my project and agree with @fjebaker assessment of what's happening. The problem arises due to changes in the Zig master branch where the path to the emsdk headers must be a relative path, as mentioned here. Previously, in versions >= 0.12, this path was absolute.

This code in the src/build.zig is checking that the path is absolute:

var dir = std.fs.openDirAbsolute(cache_include, std.fs.Dir.OpenDirOptions{ .access_sub_paths = true, .no_follow = true }) catch @panic("No emscripten cache. Generate it!");
dir.close();

However, we need to pass a relative path to b.path(cache_include) to avoid the error sub_path is expected to be relative to the build root, but was this absolute path:

raylib.addIncludePath(b.path(cache_include));

---

Ideally, I'd like to be able to use raylib's master branch with Zig's master branch. To resolve this in a way that doesn't break existing code but enables new development also I propose something like this:

if (comptime builtin.zig_version.minor > 12) {
    var dir = std.fs.cwd().openDir(cache_include, std.fs.Dir.OpenDirOptions{ .access_sub_paths = true, .no_follow = true }) catch @panic("No emscripten cache. Generate it!");
    dir.close();
    raylib.addIncludePath(b.path(cache_include));
} else {
    var dir = std.fs.openDirAbsolute(cache_include, std.fs.Dir.OpenDirOptions{ .access_sub_paths = true, .no_follow = true }) catch @panic("No emscripten cache. Generate it!");
    dir.close();
    raylib.addIncludePath(.{ .path = cache_include });
}

I've made those changes in a fork here, happy to submit a pull request if others agree this change makes sense.

[CosmicBagel]

My apologies for breaking this for you, I should have tested this code path properly with 0.12.0 before submitting the PR, that's on me.

Indeed, zig is making a push to eliminate all absolute paths in the build system it seems ziglang/zig#18450
Context: andrewrk is the BDFL for zig, so if he's pushing to have it happen, it will most likely happen.

I like the approach dylan proposed here, the only thing I would like to add is maybe a warning that gets printed when using zig 0.12.0 so that people will be aware of future breakage when upgrading to zig 0.13.0. I'm assuming people have little scripts and shell aliases, shell variables, ect, that point to this.

[CosmicBagel]

Ah dang, I was too slow

[fjebaker]

Thanks @dylanlangston and @CosmicBagel, the changes merged work for me. Thanks for addressing this so quickly!

Context: andrewrk is the BDFL for zig, so if he's pushing to have it happen, it will most likely happen.

I absolutely love the direction Andrew is taking Zig in! Until the language has arrived at its stable API, these are just the little hacks we'll have to put up with (~;