I’m currently working on a hobby OS (which I may also post about if I ever finish getting to userland), and I’ve been running into build issues on CI only on macos and windows (which I can only replicate on github CI since I work on this project mostly on my linux box).
I pull in various projects through the package manager in my build.zig.zon (as part of a long term goal to be able to drop in build+run on any target), and the build is failing with git being unable to unpack these deps. The confusing part here is that these are all lazy dependencies so I would have though nothing should be pulled in anyway as my CI is set up to not use these .
Here’s an example of the unpacking failure
Very likely that there’s a pair of file paths that only differ in their casing (e.g. foo/bar and foo/BAR). Windows and MacOS typically have case-insensitive filesystems.
Sure, but what does that amount to then? A zig fetch bug/defect? Or something I’m doing wrong (which I can’t see what that would be just yet)? All I’m doing is building with all LazyDependencies unused, I would think it would be up to the zig package manager to resolve directory existence/cache misses on its own
That’s quite a complicated build script. Are you running multiple zig build simultaneously? Because it looks like a race condition to me. lazyDependency is checking if the package is there, it isn’t, then it tries to fetch it, but it fails because, in the meantime, someone already put the package there. If I’m correct, rerunning the script now that the package is already fetched should work.
Zig supports packages that contain files that may be unsupported by some file systems. This is necessarily true, because you could invent a file system tomorrow that forbids files whose sizes are prime numbers, and that doesn’t mean Zig suddenly has a bug that wasn’t there yesterday. It’s up to those creating packages to avoid tripping common file system pitfalls.
In more concrete terms, it’s a valid use case to use Zig to fetch packages that have files with names differing only in case, and to use those packages only on operating systems that support such things.
Nope, or at least this shouldn’t be (but github CI is well known for being ugly around the edges). This should just be running 4 sequential runs of the “kernel” step, each with slightly different build flags
1 Like
zig build supports being run simultaneously. The cache system uses advisory file locking to accomplish this.
Here we see since they’re both waiting on the same resource, one process does the work while the other waits for it.
1 Like
