gpu-dawn: Building on Windows - FileNotFound error in gpu-dawn build #315
Labels
No labels
CI
all
basisu
blog
bug
build
contributor-friendly
core
correctness
deferred
dev
direct3d-headers
docs
driver-os-issue
duplicate
dxcompiler
editor
examples
experiment
feature-idea
feedback
flac
freetype
gamemode
gkurve
glfw
gpu
gpu-dawn
harfbuzz
help welcome
in-progress
infrastructure
invalid
libmach
linux-audio-headers
long-term
mach
mach.gfx
mach.math
mach.physics
mach.testing
model3d
needs-triage
object
opengl-headers
opus
os/linux
os/macos
os/wasm
os/windows
package-manager
priority
proposal
proposal-accepted
question
roadmap
slipped
stability
sysaudio
sysgpu
sysjs
validating-fix
vulkan-zig-generated
wayland-headers
website
wontfix
wrench
www
x11-headers
xcode-frameworks
zig-update
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
hexops/mach#315
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This may be something very obvious that I have done wrong, being completely new to Zig.
I've tried running the homepage commands on Windows, and ran into the developer mode problem.
After working around this, and also updating all the
.paths to.sourcein the build files, I was able to compile the build file.However, the build fails at:
(I can supply full trace if necessary)
This is a CreateProcess which tries to run Git -
gitis definitely 100% on the PATH, and I can run it from the same command line env that I'm runningzig buildfrom. (Althoughgitis under Program Files - I haven't tried putting it in a dir with no spaces).I know Zig historically had issues running windows programs that weren't in the CWD, but they were all closed over a year ago (eg https://github.com/ziglang/zig/issues/4120).
Is there anything obviously wrong I'm doing?
Running zig version 0.10.0-dev.2431+0e6285c8f
Addendum - putting
gitin c:\git (and updating path) makes no difference.i've seen similar error trying to build without git present. right now mach's build.zig doesn't produce a proper error if git is not seen by zig build.
there is a pr #316 to check for git.
can you please try to build again when it merges?
Tried to build a minimum repro:
This worked fine. Git is present and runs ok.
Made me wonder if the error was in
thisDir, and possibly related to the Windows symlink nonsense, so I changed into thegpu-dawnfolder and ranzig build- it downloaded the dawn_x86...lib.gz and headers.json.gz and appeared to complete successfully.I'll keep poking.
@cocoademon I'm pretty sure this is the issue you're running into, in the FAQ: https://github.com/hexops/mach/blob/main/doc/known-issues.md#windows-file-not-found
I am hoping to eventually eliminate all symlinks from the codebase to avoid this issue on Windows (their symlink approach is crazy bad out of the box.) Where could I have linked these docs so that you might have seen them?
@slimsag I think you're right, but there are two problems here.
I followed the "developer mode" steps to as the first thing I did. That FAQ was the first thing I found, so no need to do a better job linking it. (I didn't follow the WSL approach as I didn't want to go through another installation hurdle)
I created a minimal build using
zig init-exeand was able to reproduce the error wheregitwasn't found on the path but only duringzig build.This appears to have been a known problem: https://github.com/ziglang/zig/issues/10561 with a resolution that might not have landed in master yet.
Switching my Windows 10 Path env var to PATH instead solved it in the minimal repro, and now gives me a different error while building Mach:
"Directory name invalid" in CreateProcessW is weird, and it's caused by setting the CWD to an invalid path.
I threw a std.debug.print into the
getCurrentGitCommitfunction, and found that@src().fileis set to the full symlink dir:C:\projects\mach\gpu\libs\mach-gpu-dawn\build.zig.I can't CD into this path, so I presume that there needs to be some canonicalization.
As a test fix, I hardcoded
thisDirin gpu-dawn/build.zig to the following:and Success! It's running some Boids!
It seems like Windows can't have a CWD with a symlink in it when calling CreateProcessW. I'm trying to figure out a more robust solution - there's no obvious "canonicalize path" function in Windows.
Things I've tried instead of hardcoding the gpu-dawn path:
dirname(@src().file))and just using ".".OK, makes sense, thanks for reporting this. I do think we could solve this with
std.os.realpath- but for me this just reiterates, again, how bad/annoying symlinks are to deal with on Windows.I'll just aim to eliminate all symlinks. If someone wants to PR the
std.os.realpathsolution feel free to!thisDir(sdkPathnow) is mostly used in comptime concats, whilestd.os.realpathrequires runtime computationClosing in favor of https://github.com/hexops/mach/issues/587