This upgrades us to the latest master (pre-release) version of GLFW which has our patches
for undefined behavior in Zig, effectively moving us off of our temporary fork. We now track
GLFW upstream at the revision documented in https://github.com/hexops/glfw/blob/main/VERSION
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
Co-authored-by: Cai Bingjun <1945458160@qq.com>
Moving to the same model we use elsewhere: we now have https://github.com/hexops/glfw
which is a tiny repository with only the sources needed to compile/build/test GLFW on
every platform. It's just the upstream repository at a specific commit, recorded in
the `VERSION` file.
Helps hexops/mach#343
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.
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>
