hexops/mach

zig game engine & graphics toolkit

mach's Issues

build: Mac M1 / aarch64 support

Currently not possible due to GitHub actions not having M1-based runners: actions/runner-images#2187

Considering getting an M1 device for this.

update system_sdk to reflect new Zig macOS version targeting

Since ziglang/zig#10215 Zig will ship versioned libc headers and allow specifying the following target triples for macOS:

* supported triples:
  
  * 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)

We should reflect this change by:

1. Revert the temporary hack to allow compilation with macOS 12 frameworks 7d47233
2. Default to the same macOS version as Zig (well, in reality Zig defaults to 10 but we only have an 11 SDK, so we'll default to that even when Zig targets 10 which is fine and we know works. In the future, we'll continue to target the same SDK as Zig)
3. When the target triple is -macos.12, have system_sdk.zig detect that and use the new https://github.com/hexops/sdk-macos-12.0

gpu-dawn: iOS support

Step 1 is probably getting mach/gpu (Dawn, specifically) compiling for iOS.

Then we'll need something like the iOS support mentioned in https://zigmonthly.org/letters/2021/august/ to actually build an iOS binary that we can use.

Probably also chat with @MasterQ32 because he's mentioned wanting to do similar stuff in the past and might get to it before me / have insight I don't have yet.

Lastly will be building an "app" abstraction on top of iOS+Android+Web+GLFW APIs for getting a WebGPU window.

Friendlier GLFW API initialization

We should also do what this issue proposed for glfw.Init, as there are init hints for GLFW (and potentially one other type of hint? I forget off the top of my head)

Originally posted by @slimsag in #65 (comment)

glfw: do not use sysroot for SDK inclusion

Setting sysroot on the builder means that anything not found in our system SDKs cannot be included/linked against. That is very important to avoid.

Better to just set the right include paths, lib include dirs, etc.

GLFW: ziggify the enum declarations

The way the enums are set up right now is very C-like, should clean this up.

Also consider #27 (comment)

gpu-dawn: x86_64-windows support

• #167
• Publish binary releases of gpu-dawn for Windows
• #169
• Build DirectXShaderCompiler with zig build system
• Land patches to gpu-dawn/build.zig required for Windows builds
• Update and publish WIDL-produced Direct3D headers in a Windows SDK repo
• Add Windows SDK repo to system_sdk.zig for use in mach/gpu-dawn
• Merge patches to Dawn into main of our fork,
  • hexops/dawn#8
  • hexops/dawn#7
  • hexops/dawn#6
• Patch Dawn to eliminate dependency on windows.ui.* headers and fix other issues building with Zig
  • hexops/dawn#8
  • hexops/dawn#7
  • hexops/dawn#6
• Debug the compatibility issues with DX debug API expecting 3 params in Dawn vs. 1 according to headers (???) -> most likely due to outdated d3d12 headers.
• Debug cause of segfaults that occurred when hacking in updated d3d headers (see COM calling convention issues discussed at ziglang/zig#9998 (comment))
• Produce up-to-date MinGW/GNU compatible Direct3D headers ziglang/zig#9998 (comment)

mach: Browser support

Meta issue related to #21

gpu: x86_64-macos support

gpu-dawn: Android support

Similar to #88 - get mach/gpu (Dawn) compiling for Android and look at using https://github.com/MasterQ32/ZigAndroidTemplate

infrastructure: automate sub-repository synchronization

Set up a GitHub action or something that periodically runs the (currently manual) process to sync sub-repositories:

./dev/push-subrepos.sh

Also we should remove ./dev/pull-subrepos.sh now that it is often ineffective (and we don't accept PRs to subrepos to avoid the complex merge conflicts that can arise even in simple cases)

introduce intermediate lib for GLFW compilation

glfw.link currently from a project adds C sources to the compilation step, rather than linking an intermediate library, and so if you're using it from you're own project with C/C++ code compilation can be slower.

We should default to emitting a static lib, and making glfw.link link to that.

mach-glfw doesn't build with latest Zig master

Latest Zig master has several fixes for macOS framework linking which means some very awkward workaround behavior we had in place to avoid some linker issues is now fixed, and master no longer builds:

warning(link): unable to resolve dependency /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
warning(link): unable to resolve dependency /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
error(link): undefined reference to symbol '_CGSetDisplayTransferByTable'
error(link):   first referenced in '/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/92047481a1a97318e7889499d8a2924f/libglfw.a(/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/c41a8e5da0f2f5ed783557aa4cfa1679/cocoa_monitor.o)'
error(link): undefined reference to symbol '_CGReleaseDisplayFadeReservation'
error(link):   first referenced in '/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/92047481a1a97318e7889499d8a2924f/libglfw.a(/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/c41a8e5da0f2f5ed783557aa4cfa1679/cocoa_monitor.o)'
error(link): undefined reference to symbol '_CGOpenGLDisplayMaskToDisplayID'
error(link):   first referenced in '/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/92047481a1a97318e7889499d8a2924f/libglfw.a(/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/c41a8e5da0f2f5ed783557aa4cfa1679/cocoa_monitor.o)'
error(link): undefined reference to symbol '_CGGetOnlineDisplayList'
error(link):   first referenced in '/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/92047481a1a97318e7889499d8a2924f/libglfw.a(/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/c41a8e5da0f2f5ed783557aa4cfa1679/cocoa_monitor.o)'
error(link): undefined reference to symbol '_CGGetDisplayTransferByTable'
error(link):   first referenced in '/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/92047481a1a97318e7889499d8a2924f/libglfw.a(/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/c41a8e5da0f2f5ed783557aa4cfa1679/cocoa_monitor.o)'
error(link): undefined reference to symbol '_CGDisplayVendorNumber'
error(link):   first referenced in '/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/92047481a1a97318e7889499d8a2924f/libglfw.a(/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/c41a8e5da0f2f5ed783557aa4cfa1679/cocoa_monitor.o)'
error(link): undefined reference to symbol '_CGDisplayUnitNumber'
error(link):   first referenced in '/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/92047481a1a97318e7889499d8a2924f/libglfw.a(/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/c41a8e5da0f2f5ed783557aa4cfa1679/cocoa_monitor.o)'
error(link): undefined reference to symbol '_CGDisplaySetDisplayMode'
error(link):   first referenced in '/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/92047481a1a97318e7889499d8a2924f/libglfw.a(/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/c41a8e5da0f2f5ed783557aa4cfa1679/cocoa_monitor.o)'
error(link): undefined reference to symbol '_CGDisplayScreenSize'
error(link):   first referenced in '/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/92047481a1a97318e7889499d8a2924f/libglfw.a(/Users/slimsag/Desktop/hexops/mach/glfw/zig-cache/o/c41a8e5da0f2f5ed783557aa4cfa1679/cocoa_monitor.o)'

We just need to properly link the frameworks now, but doing so will require anyone using mach-glfw be up-to-date with latest Zig master:

Window.setIcon tests failing

Probably on all window managers, maybe on Windows too?

In my case xfce4 (it fails on my Ubuntu based distro called Linux Lite and the Garuda/Arch distro).

I can reproduce at least on Ubuntu 20.04 vanilla.

gpu: build idiomatic Zig interface to WebGPU, abstract away native+browser support

This would give us a truly nice, cross-platform, seamless graphics API across browsers, mobile and desktop via Vulkan, Metal, and OpenGL as fallback.

Use the same Zig API for:

• WebAssembly (browser's implementation)
• Mobile (dawn or gfx-rs/wgpu-native backend, at your choosing)
• Desktop (dawn or gfx-rs/wgpu-native backend, at your choosing)

This is also the only truly cross-platform graphics API being blessed by major vendors (e.g. Apple) which leads me to believe it has a real shot long-term at displacing the tried and true Vulkan+Metal+OpenGL combo. And even if it doesn't, there has been a massive undertaking to offer a unified API of that Vulkan+Metal+OpenGL combo in forming WebGPU that very few will be able to effectively beat in the general case (e.g. I think we can effectively beat Godot's, potentially Unity and Unreal's, graphics API abstractions using WebGPU.)

mach: Browser support

look into how to make this process nice, a unified app/window creation API, etc.

build: Windows -> Mac (aarch64/x86_64) cross compilation fails?

zig build test -Dtarget=x86_64-macos

fails on Windows with error: Unexpected when ran from a Windows host OS.

Maybe an issue in final linking? Maybe it's trying to run the Mac binary? Needs investigation

glfw: add support for cross-compiling for Wayland

Reported by @alichraghi in #75 (comment)

we will need to add the right apt packages to the fetch.sh script here so our SDK has the headers/libs so we can cross compile for Wayland. https://github.com/hexops/sdk-linux-x86_64

It is worth noting that it may be worth waiting until GLFW's Wayland backend (which today is still very immature I think) improves, e.g. in the next version of GLFW there will be support for choosing between X11 and Wayland backends at runtime and so we should begin building for both by default. glfw/glfw#1958

system_sdk: Vulkan and OpenGL cross compilation

The Mach system SDKs should include what is necessary for mach-glfw to cross-compile when using Vulkan and OpenGL. This likely just requires including the right libraries etc. in the system SDKs. Currently included is:

• MacOS: Everything for GLFW, OpenGL and Metal development. Missing Vulkan development.
• Linux: Everything for GLFW. Missing OpenGL and Vulkan development.
• Windows: Zig includes OpenGL support I believe. Missing Vulkan.

This work will be easy to reuse for anybody wishing to cross-compile / build their own OpenGL/Vulkan code in Zig as well. See https://github.com/hexops/mach/blob/main/glfw/system_sdk.zig

Other things that I've heard from the incredible @Snektron regarding Vulkan cross compilation:

By the way, i can let you on in on a secret, and that is if you wish to impress andrew you can make a completely static linux binary by integrating the amdvlk stack directly

I also have GenerateStep.initFromSdk [in vulkan-zig] which can help you fetch vk.xml, "which might also be interesting to know for your system sdk setup

getInstanceProcAddress can't be used with zig-vulkan

glfwGetInstanceProcAddress is used in zig-vulkan to gather all function addresses required for the requested vkInstance. Here is a generated code example:

        //          v--- Loader here is glfwGetInstanceProcAddress 
        pub fn load(loader: anytype) !Self {
            var self: Self = undefined;
            inline for (std.meta.fields(Dispatch)) |field| {
                const name = @ptrCast([*:0]const u8, field.name ++ "\x00");
                const cmd_ptr = loader(.null_handle, name) orelse return error.CommandLoadFailure;
                @field(self.dispatch, field.name) = @ptrCast(field.field_type, cmd_ptr);
            }
            return self;
        }

In the definition of glfw.getInstanceProcAddress there are two major issues.

1. Function is inlined. This means the call convention is not transitive with zig-vulkan which expect a vulkan_call_conv which is defined as:

pub const vulkan_call_conv: std.builtin.CallingConvention = if (builtin.os.tag == .windows and builtin.cpu.arch == .i386)
    .Stdcall
else if (builtin.abi == .android and (builtin.cpu.arch.isARM() or builtin.cpu.arch.isThumb()) and std.Target.arm.featureSetHas(builtin.cpu.features, .has_v7) and builtin.cpu.arch.ptrBitWidth() == 32)
    // On Android 32-bit ARM targets, Vulkan functions use the "hardfloat"
    // calling convention, i.e. float parameters are passed in registers. This
    // is true even if the rest of the application passes floats on the stack,
    // as it does by default when compiling for the armeabi-v7a NDK ABI.
    .AAPCSVFP
else
    .C;

2. The returned signature does not match. mach-glfw define the return value as Error!?VKProc while glfw define it as ?VKProc

I'm unsure how this should be resolved, but two suggestions are:

• Make a builder for the function that takes a ABI = enum { Preserved, NotPreserved } where based on input enum it returns either current implementation or a true to ABI function
• Rewrite function to preserve ABI

glfw: Vulkan loading base handle panics in release

Inital issue was filed in the vulkan example as I though it was a bug in that code and can be found here

The following will panic in release (but not in debug):

const vk_proc = @ptrCast(fn(instance: vk.Instance, procname: [*:0]const u8) vk.PfnVoidFunction, glfw.getInstanceProcAddress);
self.vkb = try BaseDispatch.load(vk_proc);

replacing the following code in mach-glfw resolves the issue:
vulkan.zig

pub fn getInstanceProcAddress(vk_instance: ?*opaque {}, proc_name: [*:0]const u8) callconv(.C) ?VKProc {
    const proc_address = c.glfwGetInstanceProcAddress(if (vk_instance) |v| @ptrCast(c.VkInstance, v) else null, proc_name);
    getError() catch |err| @panic(@errorName(err));
    if (proc_address) |addr| return addr;
    return null;
}

with

pub const getInstanceProcAddress = c.glfwGetInstanceProcAddress;

glfw: future: test user defined compile errors

Since #32 add calls to @compileError, the test suite should include scenarios where a compile error is expected. Currently this is not possible pending issue 513 in zig

mach: Android support

Look into the best way to approach Android support. Maybe something like a Zig port of https://github.com/brackeen/glfm initially.

build: MacOS sdk query panic

Hey @slimsag,

When building the test from the root directory for MacOS on Linux...if I just hit 'enter' to accept the seeming 'Y' default for the MacOS SDK install question from build.zig:336, then I get an integer overflow error and stack trace from zig. Simple fix, I suppose, but I wasn't sure if you wanted to force a user to actually type some answer there for legal reasons, so I will leave it up to you. I didn't test on Windows

CI: M1 mac CI pipeline

Need a CI pipeline to test building from M1 mac.

Note: GitHub actions doesn't support this yet, actions/runner-images#2187 - but I may be able to set up the M1 mac I bought for developing Mach a few days ago as an actions runner. Need to look into how hard this is to set up.

generalize system SDK inclusion

Today, we have special build logic in https://github.com/hexops/mach/blob/main/glfw/build.zig which:

• git clones the relevant system SDK repos https://github.com/hexops/sdk-macos-11.3 and https://github.com/hexops/sdk-linux-x86_64 needed to cross-compile GLFW
• Handles asking the user for license agreement, in the case of the MacOS SDK which is distributed under Apple's XCode licensing terms.
• Handles including the relevant directory paths, etc.

This logic is useful outside of just our GLFW bindings, though. For example, it is useful to use this for cross-compiling Google's Dawn WebGPU implementation.

It would also be useful to be able to use this logic outside of Mach entirely, for example to cross compile SDL applications @MasterQ32 MasterQ32/SDL.zig#8 - or maybe for @Avokadoen to cross-compile https://github.com/Avokadoen/zig_vulkan perhaps

Idea: Move this logic into a new system_sdk library, so that one can easily import / benefit from this logic.

Challenge: I don't think these SDKs will always include all system libraries, for example the Linux one picks a very specific set of packages - just those required to build Mach. And it would be nice to slim down the MacOS one even further (currently ~164M). Additionally, it's possible that the versions Mach uses are not what others want, or may change over time. So one important thing here will be making it so that people can very easily fork the SDK repos to modify which system libraries are included, and use their fork if preferred - although probably it'll just work fine in most cases.

Question: Does anyone actually want this? Does this sound useful?

getClipboardString test failing on x86_64-linux

https://github.com/hexops/mach-glfw/runs/3989354270?check_suite_focus=true

glfw: typo prevents building for Wayland

Reported by @alichraghi in #75 (comment)

mach: rendering backend implementation

general issue for tracking this + notes related to it

(regression) x86_64-macos -> aarch64-macos cross compilation failing after update to Zig master

After updating to latest Zig master #107 we find an intriguing failure when cross compiling x86_64-macos -> aarch64-macos.

Notably, linux/windows -> aarch64-macos do not fail.

https://github.com/hexops/mach/runs/4339864442?check_suite_focus=true

glfw.Window.Size should be public

It's returned by public APIs (glfw.Window.getSize etc), so it's inconvenient to have the type be private.

glfw: Force init before using init dependent functions

glfws order dependent API design makes sense according to glfw implementation, but is quite silly from a glfw user perspective. I'm confident we can improve the API (hopefully without deviating too much from the C API)

My previous suggestion did not turn out well. Now, vulkan is a very big API, but one thing that I realized is that the design of the API makes it impossible to call functions in the wrong order by forcing you to instantiate an vkInstance that you then can call functions from. This is again used for later concepts in Vulkan. This concept can be used in the glfw API too!

If init expose all functions that require init through a returned struct, then we can make it impossible to end up with the init error scenario, and this pattern can be used for other similar order dependent function (if there are any)

const glfw_entry = @import("glfw");

pub fn main() !void {
    const glfw = try glfw_entry.init(); // use returned API struct
    defer glfw.terminate();

    // Create our window
    const window = try glfw.Window.create(640, 480, "Hello, mach-glfw!", null, null);
    defer window.destroy();

    // Wait for the user to close the window.
    while (!window.shouldClose()) {
        glfw.pollEvents();
    }
}

glfw: maintain C ABI compatability for OpenGL proc addrs

Same as #49 but for OpenGL

build: Building on ArchLinux is failing because of Metal

When trying to run hello-triangle example in the webgpu folder on dawn branch on Manjaro, building the project results into the linking error

ld.lld: error: undefined symbol: dawn_native::metal::Connect(dawn_native::InstanceBase*)
>>> referenced by Instance.cpp:142 (libs/dawn/src/dawn_native/Instance.cpp:142)
>>>               /home/plony/projects/mach/webgpu/zig-cache/o/24dfbf1398b301943d0ad3e68f08b02d/Instance.o:(dawn_native::InstanceBase::EnsureBackendConnections()) in archive /home/plony/projects/mach/webgpu/zig-cache/o/d73b01ef2cd4093c849a311c52ee6344/libdawn.a

ld.lld: error: undefined symbol: dawn_native::InheritsFromCAMetalLayer(void*)
>>> referenced by Surface.cpp:55 (libs/dawn/src/dawn_native/Surface.cpp:55)
>>>               /home/plony/projects/mach/webgpu/zig-cache/o/c8b8335d201d3282f328e370fa662d9a/Surface.o:(dawn_native::ValidateSurfaceDescriptor(dawn_native::InstanceBase const*, dawn_native::SurfaceDescriptor const*)) in archive /home/plony/projects/mach/webgpu/zig-cache/o/d73b01ef2cd4093c849a311c52ee6344/libdawn.a

ld.lld: error: undefined symbol: utils::CreateMetalBinding(GLFWwindow*, WGPUDeviceImpl*)
>>> referenced by BackendBinding.cpp:81 (libs/dawn/src/utils/BackendBinding.cpp:81)
>>>               /home/plony/projects/mach/webgpu/zig-cache/o/31f70a29fc699c7d51dfac551e7785b5/BackendBinding.o:(utils::CreateBinding(wgpu::BackendType, GLFWwindow*, WGPUDeviceImpl*)) in archive /home/plony/projects/mach/webgpu/zig-cache/o/d73b01ef2cd4093c849a311c52ee6344/libdawn.a
error: LLDReportedFailure

browsing the Surface.cpp and BackendBinding.cpp resulted in finding out that, preprocessor thinks that DAWN_ENABLE_BACKEND_METAL is defined somewhere. I tried to delete the local repository and do git clone -b dawn --recursive https://github.com/hexops/mach but the error still appears

glfw: tracking issue for ensuring upstream patches land

• do not rely on undefined behavior in glfwSetWindowIcon for X11 glfw/glfw#1986
• Fix undefined behaviour in X11 keypress handling glfw/glfw#1989
• Add possible errors comment glfw/glfw#2007
• Add possible error comment glfw/glfw#1998
• update docstring which inaccurately says GLFW_CONTEXT_REVISION is a window hint glfw/glfw#1992
• 7d47233
  • ziglang/zig#10202
  • ziglang/fetch-them-macos-headers#15
  • #102

gpu: x86_64-linux support

glfw: potential memory leak reported by valgrind

please compile minimal example and run
$valgrind --leak-check=full --show-reachable=yes program

gpu: ensure Zig ObjC++ support lands

Building the gpu library in this repo currently requires a version of Zig with ziglang/zig#10096 built in, this issue is for me to periodically check in on that PR and make sure it lands in master / future releases of Zig

glfw: add comptime enforcement of init

as suggested in #49 (comment)

build: XCode Command Line Tools are required (Zig bug)

Even if (*Builder).sysroot is set to a Mac OS SDK, the latest Zig persistently invokes xcrun so one must dismiss a number of prompts to install XCode and re-run the relevant Zig build command multiple times before build succeeds.

getSDKPath here invokes xcrun internally: https://sourcegraph.com/github.com/ziglang/zig@e02caa7e2909c0ae7f7e8ea1378d78e0469b9ff8/-/blob/src/main.zig?L1724-1737

It would be nice if it didn't, at least when we set sysroot but perhaps even without(?) so that we could supply the relevant MacOS SDKs ourselves and not have any dependency on XCode.

build: Linux x86_64 support

glfw: Denormalize Errors

In the original draft of #92, I added an off-the-cuff change to de-normalize error sets. As suggested by @slimsag, I'm opening an issue to discuss this change (and whether it's beneficial enough to consider adding).

Currently, we have normalized errors, adhering to the general possibility imposed by GLFW of (almost) any function returning (or rather "setting") any of the errors specified by the library. But it is important to note that GLFW does obviously specify, for each function, its "possible" error set, and according to the maintainer of GLFW, this documentation is "generally accurate" (paraphrased).

A consideration here is ABI stability: with a normalized error set, that's (almost universally) a guarantee, whilst with denormalized error sets, that's essentially impossible unless we were to freeze the GLFW version.

The other consideration here is how "comfortable" the API is: while a comment describing which errors you might encounter is alright, it is a departure from the error handling philosophy of Zig, and much more akin to C (which is what GLFW aims to cater to). Denormalized errors would slightly increase maintenance, but it would vastly improve readability, given that the errors the user would have to handle would be in the function's signature, and makes it such that a compilation error will be emitted if the user tries to catch an error which the function can't emit.

As well, another positive of denormalized errors would be behaviour-documentation parity. If GLFW changes the behaviour of one of their functions, and adds a possible error to a function, then we'll catch unreachable on that prong, and be able to make a PR upstream to update their docs. Net positive.

I am in favour of denormalized errors.

mach: iOS support

Look into the best way to approach iOS support. Maybe something like a Zig port of https://github.com/brackeen/glfm initially.

glfw.window.hint should accept enum, bool, or string and defer to right underlying GLFW function

glfwWindowHint can take an enum or GLFW_FALSE/GLFW_TRUE, and glfwWindowHintString takes a string. We should just expose a single glfw.window.hint Zig API that accepts anytype and defer to the right underlying GLFW function based on the type.

build: Windows x86_64 support

gpu: aarch64-macos cross compilation support

macOS: mach-glfw fails to build with "unrecognized file extension of parameter"

Hello, thanks for making this, and specifically mach-glfw.
After following the instructions over at hexops/mach-glfw,
I'm getting this error message when running zig build in my project directory:

error: unrecognized file extension of parameter '/Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/cocoa_joystick.m'
glfw...The following command exited with error code 1:
/usr/local/Cellar/zig/0.8.1_1/bin/zig build-lib /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/src/main.zig -cflags -D_GLFW_COCOA -- /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/cocoa_joystick.m /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/cocoa_init.m /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/cocoa_window.m /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/cocoa_time.c /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/cocoa_monitor.m /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/nsgl_context.m /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/posix_thread.c /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/monitor.c /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/init.c /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/vulkan.c /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/input.c /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/osmesa_context.c /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/egl_context.c /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/context.c /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/src/window.c -lc -lobjc --cache-dir /Users/kai/Desktop/test-zig-glfw/zig-cache --global-cache-dir /Users/kai/.cache/zig --name glfw -I /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/glfw/include -I /Users/kai/Desktop/test-zig-glfw/libs/mach-glfw/upstream/vulkan_headers/include -isystem /Users/kai/Library/Application Support/hexops/sdk-macos-11.3/root/usr/include -L /Users/kai/Library/Application Support/hexops/sdk-macos-11.3/root/usr/lib -F /Users/kai/Library/Application Support/hexops/sdk-macos-11.3/root/System/Library/Frameworks -framework CoreFoundation -framework IOKit -framework Metal -framework AppKit --enable-cache
error: the following build command failed with exit code 1:
/Users/kai/Desktop/test-zig-glfw/zig-cache/o/e9c19e6662dcdc3b60a5c83de2450890/build /usr/local/Cellar/zig/0.8.1_1/bin/zig /Users/kai/Desktop/test-zig-glfw /Users/kai/Desktop/test-zig-glfw/zig-cache /Users/kai/.cache/zig

The build.zig looks like this:

const std = @import("std");
const glfw = @import("libs/mach-glfw/build.zig");

pub fn build(b: *std.build.Builder) void {
    const exe = b.addExecutable("test-zig-glfw", "main.zig");
    exe.addPackagePath("glfw", "libs/mach-glfw/src/main.zig");
    glfw.link(b, exe, .{});
}

Darwin macmini.local 21.1.0 Darwin Kernel Version 21.1.0: Wed Oct 13 17:33:23 PDT 2021; root:xnu-8019.41.5~1/RELEASE_X86_64 x86_64

Let me know if you need more information.
Please note that this is the very first time I have ever tried to build anything with zig, so I might have missed something crucial.

glfw: Friendlier window creation

GLFW's C API uses "window hints", which aren't hugely user friendly. In Zig, we can do much better by using an "options" struct with default values. My own GLFW wrapper does this for GLFW's window creation, which makes the API much nicer in my opinion.

It could be argued this deviates too far from the C API, but at the same time it doesn't really change much - just combines a few function calls into one, making the API use Zig idioms. I think of it similarly to error handling.

Here's an example of how window creation could look using an options struct:

const window = try glfw.Window.create(640, 480, "Hello, mach-glfw!", .{
    .monitor = monitor,
    .context_version_major = 4,
    .context_version_minor = 5,
    .opengl_profile = .core,
});

glfw: Eliminate `Error.InvalidValue`

Before any work is done to progress #96, I think it wise to first mop up the errors we can potentially get rid of; that's already done for the now defunct Error.InvalidEnum, but that remains to be done for Error.InvalidValue.

This issue can serve to track discussion on that effort, but the main reason I'm opening this is because I've hit a roadblock, and would like to hear some feedback: how to deal with Joystick.updateGamepadMappings?
The GLFW call does some parsing of the passed string, and can set 'InvalidValue' if it encounters anythign unexpected, which makes preventing this error condition quite a bit more complex.

One option is to try and mimic GLFW's parsing to pre-emptively assert that the format is wrong, and perhaps deliver a useful error message to inform the caller of what's gone wrong; the other option is to simply leave the Error.InvalidValue code for this function, and allow it to be unique to it, and any other functions that may do parsing that we can't pre-empt in a maintainable fashion, which, while it doesn't allow us to eliminate the error altogether as hoped, would still be more or less made okay by error denormalization.

glfw: Illegal instruction in `pollEvents()`

Code

const std = @import("std");
const glfw = @import("glfw");
const mem = std.mem;

fn printKey(window: glfw.Window, key: glfw.Key, scancode: isize, action: glfw.Action, mods: glfw.Mods) void  {
    _ = window;
    _ = scancode;
    _ = action;
    _ = mods;
    std.debug.print("{s}\n", .{key});
}

pub fn main() !void {
    try glfw.init();
    defer glfw.terminate();

    try glfw.Window.hint(glfw.Window.Hint.context_version_major, 4);
    try glfw.Window.hint(glfw.Window.Hint.context_version_minor, 5);
    const window = try glfw.Window.create(640, 480, "Hello, mach-glfw!", null, null);
    defer window.destroy();
    try glfw.makeContextCurrent(window);
    window.setKeyCallback(printKey);

    while (!window.shouldClose()) {
        try window.swapBuffers();
        try glfw.pollEvents();
    }
}

while the above code running, if you press a keyboard key that will crash with this messsage:

Illegal instruction at address 0x26832c
lib/glfw/upstream/glfw/src/x11_window.c:0:0: 0x26832c in _glfwPlatformPollEvents (/home/ali/dev/kizi/lib/glfw/upstream/glfw/src/x11_window.c)
lib/glfw/upstream/glfw/src/window.c:1072:5: 0x274e74 in glfwPollEvents (/home/ali/dev/kizi/lib/glfw/upstream/glfw/src/window.c)
    _glfwPlatformPollEvents();
    ^
/home/ali/dev/kizi/lib/glfw/src/main.zig:189:21: 0x22b4fd in main (kizi)
    c.glfwPollEvents();