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>
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>
This substantially reduces consecutive build times when using mach/glfw.
`system_sdk.getSdkPath` is frequently invoked as part of the build process, and previously it was
doing some fairly involved work (ensuring the native SDK is at the right revision, needless
`git fetch` in native SDKs to check for updates, etc.)
We now do far less work in `getSdkPath`, and additionally cache the result in-memory. This improves
build times substantially, but especially so with consecutive (non-cold-cache) build times:
* For `mach/glfw`: ~2s before, ~160ms after
* For `mach/gpu`: , ~16s before, ~3.6s after
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.
Prior to this change, an older commit of Mach or mach-glfw would use the latest
version of the native system SDKs, which would sometimes be incompatible. Better
is to ensure that we actually pin the revision we're using, so a given revision
of mach or mach-glfw is using a specific revision of the native SDKs.
Similarly, we previously had no mechanism for updating SDKs: it was either cloned,
or it wasn't. This introduces a simple `git fetch` prior to hard-resetting the SDK
to the target pinned revision - effectively giving us automatic updates for anyone
using an older revision.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
