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.
* 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>
This consistently shaves off about 40ms (~130ms -> ~90ms, 30% reduction) from build times when iterating.
On Windows, I suspect the result will be much greater due to slow filesystem perf there and the fact
that this reduces the # of files read.
This was originally brought to my attention as a possibility by @meshula in hexops/dawn#2, the way this
works is by reducing compilation units so that C headers only need to be read/parsed/interpreted once
rather than once per individual C source file we are compiling.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
The GLFW implementation takes a constant pointer to a `VkAllocationCallbacks` struct; casting it to a mutable pointer equivalent here doesn't break anything, but does prevent passing a valid const pointer, which is often what one should prefer to do.
As well, the `@alignOf` builtin takes the alignment expected of the type directly, so `@alignOf(*T)` returns the alignment of `*T`, not `T`, so that has also been corrected.
The latest Zig master supports specifying a specific macOS version for libc, via
the target triple (ziglang/zig#10215):
* x86_64-macos.10 (Catalina)
* x86_64-macos.11 (Big Sur)
* x86_64-macos.12 (Monterey)
* aarch64-macos.11 (Big Sur)
* aarch64-macos.12 (Monterey)
Mach's `system_sdk.zig` can now download the relevant XCode framework stubs
for Big Sur (11) and Monterey (12). Although we don't have an SDK for Catalina (10)
currently, we use the Big Sur (11) SDK in that case and it generally works fine.
By default, Zig targets the N-3 version (e.g. `x86_64-macos` defaults to `x86_64-macos.10`).
Targeting the minimum supported version is useful for compatability, it guarantees the produced
binary will run on any later macOS version. Targeting the newer version can be useful if you
wish to use newer APIs not available in previous versions.
Fixeshexops/mach#102
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
Bring back the 'c.GLFW_NOT_INITIALIZED' prong in 'convertError', such that if it is ever passed that error code, we can differentiate it from just an invalid input; because it is a valid input, we just guarantee that it won't occur.
