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>
abseil-cpp now depends on `pthread.h`, it previously didn't. But this appears to
be a bug in abseil of sorts, because if you have `ABSL_FORCE_THREAD_IDENTITY_MODE` set
to `ABSL_THREAD_IDENTITY_MODE_USE_CPP11` it doesn't appear to be used/needed.
[Zig doesn't ship with pthread for the MinGW / `x86_64-windows-gnu` target](https://github.com/ziglang/zig/issues/10989),
and so the header is missing - but we don't actually need it, so we just add an
empty file to prevent the missing include error.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
`mach/gpu` has an example of how to use the bindings: https://github.com/hexops/mach/tree/main/gpu/examples
The example here is largely duplicative of that, and doesn't currently build. It would need to be updated
to reflect the latest Dawn example code.
Instead, let's keep `mach/gpu-dawn` just scoped to building Dawn with Zig. `mach/gpu` will deal with using it.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
This breaking change in the Zig stdlib is not available as a nightly build yet, so our CI will
be broken for the next day or so until that becomes available and we can update it.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
Effectively a redo of hexops/mach#231 where I messed up the submodule update by accident.
Updates Dawn to latest revision as of 2022-04-18 c7b7b6def6
* Followed https://github.com/hexops/dawn/tree/main/mach#updating
* The UB issue should now actually get fixed (once CI builds the binary releases.)
* Verified example runs on macOS.
Helps hexops/mach#221
Signed-off-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.
Some Linux distro's (e.g. Ubuntu) ship with wget but not curl by default. It's possible
to run into this if you don't use it a lot, e.g. in WSL under Windows - so produce an error
if `curl` is not installed.
Additionally, if the binary download fails, don't throw an entire stack trace to stdout.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
