This is the very, _very_, early stages of an entity component system for Mach. It's not ready
for any real use, but rather is a starting point for further development.
This spawned after [this research issue](https://github.com/hexops/mach/issues/127) in which I got
tons of great information, tips, etc. and much more research that I did after the discussion in that
issue. The idea is to start with this, and continue moulding it into what we want.
As development continues..
* I've created [a room in the Matrix server for anyone who wants to chat](https://matrix.to/#/#ecs:matrix.org)
* I'll be maintaining a blog detailing eerything I've learned and how I'm approaching development of this (as I plan to do for all key parts of Mach.)
The first article in the series:
[Let's build an Entity Component System from scatch (part 1)](https://devlog.hexops.com/2022/lets-build-ecs-part-1)
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
This change both restricts and clarifies the mutability/nullability of the pointers, and replaces the explicitly-typed pointer usage in setUserPointer with ?*anyopaque, since it now, as of being renamed from c_void, more simply communicates the intent of taking any pointer type.
repatch undefined behavior in GLFW which did not land yet and was accidentally removed when updating GLFW in #136
See glfw/glfw#1989Fixeshexops/mach#149
* add wayland-headers include path
* add wayland protocols header to wayland target includes
* move `xkb_unicode.c` to `sources_linux.c`
* glfw: document where wayland generated sources come from
* glfw: update sdk-linux-x86_64 to include Wayland protocol sources
See https://github.com/hexops/sdk-linux-x86_64/pull/2
Co-authored-by: Stephen Gutekanst <stephen@hexops.com>
This previously lead to a very long list of arguments to the compiler, so
long in fact that Windows cannot handle it.
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>
This substantially reduces consecutive build times when using mach/glfw.
`system_sdk.getSdkPath` is frequently invoked as part of the build process, and previously it was
doing some fairly involved work (ensuring the native SDK is at the right revision, needless
`git fetch` in native SDKs to check for updates, etc.)
We now do far less work in `getSdkPath`, and additionally cache the result in-memory. This improves
build times substantially, but especially so with consecutive (non-cold-cache) build times:
* For `mach/glfw`: ~2s before, ~160ms after
* For `mach/gpu`: , ~16s before, ~3.6s after
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
