The root dir of our repository has grown quite a lot the past few months.
I'd like to make it more clear where the bulk of the engine lives (`src/`) and
also make it more clear which Mach libraries are consumable as standalone projects.
As for the name of this directory, `libs` was my first choice but there's a bit of
a convention of that being external libraries in Zig projects _today_, while these
are libraries maintained as part of Mach in this repository - not external ones.
We will name this directory `libs`, and if we have a need for external libraries
we will use `external` or `deps` for that directory name. I considered other names
such as `components`, `systems`, `modules` (which are bad as they overlap with
major ECS / engine concepts), and it seems likely the official Zig package manager
will break the convention of using a `libs` dir anyway.
Performed via:
```sh
mkdir libs/
git mv freetype libs/
git mv basisu libs/
git mv gamemode libs/
git mv glfw libs/
git mv gpu libs/
git mv gpu-dawn libs/
git mv sysaudio libs/
git mv sysjs libs/
git mv ecs libs/
```
git-subtree-dir: glfw
git-subtree-mainline: 0d5b853443
git-subtree-split: 572d1144f11b353abdb64fff828b25a4f0fbb7ca
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
git mv ecs libs/
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>
* 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>
Having `glfw.getProcAddress` conform to the GLFW C ABI is important as it is often
likely to be passed into libraries which expect exactly that ABI for OpenGL function
loading.
Fixeshexops/mach#52
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
