abseil-cpp now depends on `pthread.h`, it previously didn't. But this appears to
be a bug in abseil of sorts, because if you have `ABSL_FORCE_THREAD_IDENTITY_MODE` set
to `ABSL_THREAD_IDENTITY_MODE_USE_CPP11` it doesn't appear to be used/needed.
[Zig doesn't ship with pthread for the MinGW / `x86_64-windows-gnu` target](https://github.com/ziglang/zig/issues/10989),
and so the header is missing - but we don't actually need it, so we just add an
empty file to prevent the missing include error.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
`mach/gpu` has an example of how to use the bindings: https://github.com/hexops/mach/tree/main/gpu/examples
The example here is largely duplicative of that, and doesn't currently build. It would need to be updated
to reflect the latest Dawn example code.
Instead, let's keep `mach/gpu-dawn` just scoped to building Dawn with Zig. `mach/gpu` will deal with using it.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
This breaking change in the Zig stdlib is not available as a nightly build yet, so our CI will
be broken for the next day or so until that becomes available and we can update it.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
The workflow uses a self hosted runner which is only available for
hexops/mach* repositories. Without this commit, whenever a fork of mach
or mach-* were pushed, it would queue an aarch64-mac job and then crash
after one day due to no machines being found.
Effectively a redo of hexops/mach#231 where I messed up the submodule update by accident.
Updates Dawn to latest revision as of 2022-04-18 c7b7b6def6
* Followed https://github.com/hexops/dawn/tree/main/mach#updating
* The UB issue should now actually get fixed (once CI builds the binary releases.)
* Verified example runs on macOS.
Helps hexops/mach#221
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
In e673e6c5d4 I failed to update the submodule correctly, this
commit fixes that and actually updates us to the latest Dawn revision.
Helps hexops/mach#221
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
Every library we want to link against is either provided by the Zig
toolchain or part of our SDK. Therefore, using pkg-config to link
against libraries on the host system is never what we intend.
To fix this, use linkSystemLibraryName() everywhere instead of
linkSystemLibrary() as the latter integrates with pkg-config while the
former just passes -lfoo to the zig compiler.
In combination with Zig commit 38d6e1d8a8 fixing an std.build bug,
this change fixes the linking of the necessary X11 libraries on my
x86_64 glibc based Void Linux system.
