Prior to this change, cross-compiling Mach to other OSes was not working due to a regression.
e.g. to windows:
```
zig build -Dtarget=x86_64-windows run-example-boids
LLD Link... error(link): DLL import library for -ldxguid not found
error: DllImportLibraryNotFound
error: example-boids...
```
The problem was that one build step may invoke `getSdkRoot` and the target might be for say macOS,
since it's building e.g. GLFW for macOS as the target of tests, and `getSdkRoot` would cache the
SDK root _forever_ as being the macOS SDK (in an attempt to avoid running the various git commands
needed to resolve the SDK root multiple times, which slows builds down.)
We instead need to cache the SDK root per step, because the target may not be the same.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
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>
* 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 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>
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>
Prior to this the Apple SDK license agreement prompt would appear for 11.3 but
not 12.0 by accident. This fixes the issue.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
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>
Updates us to using the newer SDK https://github.com/hexops/sdk-macos-12.0
Also enables cross-compilation of the `mach/gpu` backend for macOS.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
This refactors the logic for system SDK inclusion out of the GLFW-specific `build.zig`,
and should make it very easy for anyone to copy this file and start getting cross-platform
builds of their own OpenGL/Vulkan Zig projects.
There may be some libraries we need to add for Vulkan to these SDKs, I haven't yet tested
that - but the overall idea here seems sound.
Fixeshexops/mach#39
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
