* MacOS support functional
* C shims for dawn_native functionality, e.g. required utilities for binding to a GLFW window.
* Fully building with Zig, but depends on ziglang/zig#10096 for Obj-C++ support.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
This is a fork of Dawn which has generated sources comitted to the repo so that depot_tools,
ninja, gn, etc. are not needed.
It also enables us to track a specific version of Dawn and ensure it's compatible with our
bindings, etc.
https://github.com/hexops/dawn
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
* glfw: window hint default values parity test with attributes
* glfw: add test-mode-only variable that controls whether to set or ignore the `Window.Hints` struct passed to `Window.create`, and inline `failedToCreateWindow`
* glfw: include `context_no_error` hint/attribute in test with comment, fix oversight in `create` concerning the `defer defaultHints()` statement
Co-authored-by: Stephen Gutekanst <stephen.gutekanst@gmail.com>
* glfw: make comments into doc comments
* glfw: Publicize Window.CursorPos, Window.Size, Window.Pos, and Window.FrameSize
* glfw: Make enum value name the same format as other enum value names
* glfw: Window hints rework patch
* glfw: Relegate `Window.hint` to testing; move it down to just above the tests to reflect this, add doc comment line
* glfw: handle error `Error.InvalidEnum` explicitly, for clear error message in this unlikely edge case
* glfw: instate `Hint.context_no_error` as a hint, as it actually is specified to be a Window creation hint by the docs, and affirm removal of `Hint.context_revision`, which isn't.
The docs don't seem to specify a default value for `Hints.context_no_error` to take on, so we could set it based on `std.debug.runtime_safety` like this.
* glfw: default `context_no_error` to `false`, and added a note of caution about its usage as suggested.
* glfw: Inline enum values of `ClientApi`, `ContextCreationApi`, `ContextRobustness`, `ContextReleaseBehavior`, and `OpenGlProfile` from consts.zig, and remove the now unused constants (replaced by aformentioned enum values).
* glfw: Reference `Window.Hint` enum instead of `Window.Hints` struct to ensure fields are the same
* glfw: add comment explaining default values of `Window.Hints`
* glfw: change `OpenGlProfile` to `OpenGLProfile` based on established naming convention
* glfw: Update actual declaration of `OpenGLProfile`
* glfw: call `Window.defaultHints` after window creation, not before
* glfw: remove 'consts.zig', and move `dont_care` directly into 'main.zig'; fix anything referencing it.
* glfw: put `Window.defaultHints` into defer statement to handle cleanup in all paths
* glfw: move `Hint.focused` to match position of `Hints.focused`
* glfw: do 'zig fmt glfw/src'
* glfw: Cull `Window.Hint` comments, polish remaining; match order entirely according to current GLFW docs
* glfw: Change `Window.Hints.*Api` to `Window.Hints.*API`
Co-authored-by: Stephen Gutekanst <stephen@hexops.com>
When changes are merged to both hexops/mach and hexops/mach-glfw, we get a conflict
which is difficult to resolve with `git subtree`, particularly because we don't want
to squash commits for either repository (we prefer to maintain the full commit history
in both repos.)
Instead, require that all pull requests be sent to the main hexops/mach repository.
That's not as nice, I admit, but should be pretty easy to handle (literally just copy
changes over) and will ensure we can always keep both repos in sync easily and without
conflict.
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>
