Prior to this change, cross-compiling Mach to other OSes was not working due to a regression.
e.g. to windows:
```
zig build -Dtarget=x86_64-windows run-example-boids
LLD Link... error(link): DLL import library for -ldxguid not found
error: DllImportLibraryNotFound
error: example-boids...
```
The problem was that one build step may invoke `getSdkRoot` and the target might be for say macOS,
since it's building e.g. GLFW for macOS as the target of tests, and `getSdkRoot` would cache the
SDK root _forever_ as being the macOS SDK (in an attempt to avoid running the various git commands
needed to resolve the SDK root multiple times, which slows builds down.)
We instead need to cache the SDK root per step, because the target may not be the same.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
This issue with the previous (commented out) implementation was that by
remaking the iterator each loop, the same element was attempted to be
freed each iteration, as the element was not actually removed from the
map.
Stephen has recently created a Discord server to go alongside the Matrix chat one for people more used to Discord. I wish to add it to the README so people checking out the project can access it.
It was 4096 before. Lower values means lower latency but higher values
are needed for clear audio. It should be properly tested across multiple
browsers to find out the correct default value, or create a formula to
auto calculate it. It should always be a multiple of 2 in the range 256,
512, ..., 8192, 16384.
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>
This change makes the the Iterator generic over the components being
queried. This restores the api to the previous style with components
given to the query() function and next() having no parameters (other
that the iterator itself).
The reference to the old archetype is invalidated by getOrPut() calls of
std.ArrayHashMap. The implementation of std.ArrayHashMap means that
pointers can be invalidated on getOrPut() calls even if the key exists
in the map. This means that the reference to the old archetype needs to
be refreshed unconditionally (i.e. not only if the new archetype didn't
exist previously).