* Add shared option which builds glfw into it's own shared library
* glfw: separate shared test build step
* glfw: cleanup shared linking
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
Co-authored-by: Stephen Gutekanst <stephen@hexops.com>
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 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>
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 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>
This removes a linker hack which was preventing building with the latest
Zig master version. Of particular note, anyone wishing to use this library
will need to ensure they are up to date with latest master.
The binary releases available at https://ziglang.org/download/ (1783+eec825c and
beyond) are sufficient (really, anything released after today.)
Fixeshexops/mach#103
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
This effectively gives us the dependencies we need in any case, and works around ziglang/zig#10103
Importantly, this removes a blocker for landing WebGPU support in hexops/mach#62
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>
Previously, @Avokadoen and @mattnite ran into issues including the GLFW library
in other projects, e.g. https://github.com/Avokadoen/zig_vulkan/issues/17
In #24 we removed the intermediate static library, which solved the issue. The
problem is that when the function is invoked in the directory of the project
including GLFW, then our code:
```
const lib = b.addStaticLibrary("glfw", "src/main.zig");
```
Would refer to the project's `src/main.zig` -- not the GLFW library `main.zig`.
Although removing the intermediate lib worked around the issue, it created a
new one - slower compilation: hexops/mach#31
This fixes the issue by ensuring that the path we pass to `addStaticLibrary` is
in fact absolute, not relative.
Fixeshexops/mach#31
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
This change makes it easier to test SDKs locally, e.g. if you have:
```
% tree projects/
projects
├── mach
│ └── glfw
└── sdk-macos-11.3
```
In the `projects/mach/glfw` directory it is now easy to test changes to `sdk-macos-11.3` using:
```sh
SDK_PATH="$(pwd)/../.." zig build test -Dtarget=aarch64-macos
```
And it'll use your local SDK, instead of the one in the appdata dir.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
