hexops
build: download binaries as a build step
Currently gpu-dawn's build.zig tries to download binaries as soon as you call link; this is undesirable in the following cases:
- The user runs
zig build --helpto read the various project-specific options (maybe they are going to build Dawn from source!) - The user makes a typo, causing the build to not be executed.
- The user invokes a step that does not involve building Mach.
The solution is to create a custom build step that performs this within fn make() so that the download is deferred to when the project is actually being built, then expose the downloaded binary as a FileSource that can be referenced in steps that link to the library, for example.
As an aside, gpu-dawn should expose NO_ENSURE_SUBMODULES in the Options struct, as well as a way to override the default paths of thisDir() ++ "/libs/..." on a per-lib basis... but this gets kind of complicated when you consider that @imports have to be string literals and options reference imported code, so that might be a whole different issue...
As for system_sdk.zig: I'm not familiar enough with this script to know for sure, but I believe I saw mention of git fetch even with a custom SDK path? This should be configurable as well, but I didn't read into it too much so I might be missing something.
I created a custom "GitRepoStep" that will automatically clone a git repo for you but only when it's needed. Feel free to use it directly or as a guide for creating a new custom step: https://github.com/marler8997/zig-build-repos/blob/master/GitRepoStep.zig
Oh nice! I might look into using that for my own projects ~~if I ever make any~~.
Totally agree about making this a custom build step!
gpu-dawnshould exposeNO_ENSURE_SUBMODULESin theOptionsstruct
Sounds reasonable.
a way to override the default paths of thisDir() ++ "/libs/..." on a per-lib basis
What do you want this for? At first glance, this sounds like it would complicate things quite a lot and I'm not in favor of that. One can always fork mach/gpu-dawn if needing to make a temporary patch of some sort
I believe I saw mention of git fetch even with a custom SDK path? This should be configurable as well
Yes, that is true - but configuring where these are stored is not a good idea. Ideally every Zig project shares these SDKs because they can be a bit large (the macOS one is ~200 MB for example) - it would be bad if every Zig project out there ended up with a different copy. We git reset --hard <revision> to a specific version of the SDK prior to use, though, so you shouldn't run into any issues here.
Let me know if I missed anything, happy to accept PRs for these changes or I will get around to this eventually.
What do you want this for? At first glance, this sounds like it would complicate things quite a lot and I'm not in favor of that. One can always fork mach/gpu-dawn if needing to make a temporary patch of some sort.
I think it's important for package manager, and symlinks aren't really an option because Zig treats them as separate paths as far as I'm aware (haven't tested this myself; however, I noticed that you @bitCast options structs in the main build.zig, and I assume this is because of symlinks being treated as distinct modules).
Yes, that is true - but configuring where these are stored is not a good idea. Ideally every Zig project shares these SDKs because they can be a bit large (the macOS one is ~200 MB for example) - it would be bad if every Zig project out there ended up with a different copy. We
git reset --hard <revision>to a specific version of the SDK prior to use, though, so you shouldn't run into any issues here.
Oh thanks for explaining the SDK part. I get the reasoning and think it's fair :)
I think it's important for package manager, and symlinks aren't really an option because Zig treats them as separate paths as far as I'm aware
OK, I see what you're saying here. The important thing to note here is that gpu-dawn only has one Zig dependency: mach/glfw - you're right that is a symlink right now and that can cause some weirdness (although I actually think swapping it out today with another symlink would work totally fine.)
Soon Dawn will not have a dependency on GLFW at all, as they're moving to a different API that just requires a window handle instead of GLFW-specific code. Once that is completed, we can remove that dependency and we'll just have the C dependency (and symlinks would be fine then)
Soon Dawn will not have a dependency on GLFW at all, as they're moving to a different API that just requires a window handle instead of GLFW-specific code. Once that is completed, we can remove that dependency and we'll just have the C dependency (and symlinks would be fine then)
That's nice to hear! I'm inexperienced with graphics so this might be silly to say; but as far as I'm aware SDL is a bit more advanced than GLFW in some ways I'm interested in (for example, better multi-touch support from cursory search). But I don't have any immediate reason to have touchscreen support so that's not a huge priority for me. (I don't want to discuss pros and cons of SDL and GLFW in this thread; I was just mentioning a potential example of why it is nice to have flexibility between windowing/multimedia abstractions).
Additionally there are some Zig projects that have caught my eye (I had a discussion with xq at the Zig meetup about zero-graphics for example), so that's another reason why swapping out GLFW will be a nice thing to support; it will grant the ability to use projects that are naturally designed for Zig, and are less daunting to contribute to and/or influence than huge projects like GLFW and SDL.
This was implemented. https://github.com/hexops/mach-gpu-dawn/blob/5fe75438b824f92798c6d511d2502049f4a09c9f/build.zig#L26-L53