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 5f382f9365.
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>
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>
