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.
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.
This reverts commit 5f382f93658585d176bff75672412e4c57aa2f17.
I forgot that system include dirs also silence some warnings that are
present in system headers, so we can't really do this.
Since we're not specifying a sysroot by default (as that prevents
making use of other libraries/headers on your system, if you wish to)
we can have conflicts with either the headers on your system or the
headers Zig itself ships (although that shouldn't happen, except for
cases like Windows where we ship more up-to-date DirectX headers.)
System include dirs are treated with the same relative priority as other
system include dirs, those actually on your system and the ones Zig
provides. But regular include dirs are given higher priority, and so
should give our headers a better chance of being included in the event
that there should be any conflict.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
Yes, even in 2022 we're still dealing with Windows filepaths being too long.
The repository can't clone on GitHub actions Windows CI runner, currently,
because of this issue. https://stackoverflow.com/a/22575737
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
This effectively provides all you need to develop & cross compile DirectX 11/12
applications with `mach/glfw` (or just Zig in general, by copying `system_sdk.zig`
into your own project.)
Helps hexops/mach#86
Helps hexops/mach#59
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
This fixes compilation for msvc ABI. This currently only works under Windows,
I believe because Zig requires the Windows SDK to be present for msvc compilation
/ does not allow cross compilation with MSVC. Still, this is nice to have.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
Not sure why we had these here, but alignment on a packed struct seems somewhat
nonsensical (after all, it's fields are packed as closely together as possible
so what would alignment refer to?) removing seems fine and fixes compilation with
latest Zig:
```
/Users/slimsag/Desktop/hexops/mach/gpu-dawn/libs/mach-glfw/src/hat.zig:8:20: error: unable to override alignment of packed struct fields
up: bool align(@alignOf(u8)) = false,
^
/Users/slimsag/Desktop/hexops/mach/gpu-dawn/libs/mach-glfw/src/mod.zig:10:23: error: unable to override alignment of packed struct fields
shift: bool align(@alignOf(c_int)) = false,
``` ^
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
This change both restricts and clarifies the mutability/nullability of the pointers, and replaces the explicitly-typed pointer usage in setUserPointer with ?*anyopaque, since it now, as of being renamed from c_void, more simply communicates the intent of taking any pointer type.
repatch undefined behavior in GLFW which did not land yet and was accidentally removed when updating GLFW in #136
See glfw/glfw#1989Fixeshexops/mach#149
* add wayland-headers include path
* add wayland protocols header to wayland target includes
* move `xkb_unicode.c` to `sources_linux.c`
* glfw: document where wayland generated sources come from
* glfw: update sdk-linux-x86_64 to include Wayland protocol sources
See https://github.com/hexops/sdk-linux-x86_64/pull/2
Co-authored-by: Stephen Gutekanst <stephen@hexops.com>
