* all: build: fix sdkPath for relative @src.file
Prior to this commit, the build system heavily assumed that the result
`@src.file` would always be absolute, but this is no longer
guaranteed, likely due to there being no such thing as an "absolute
path" in WASI.
It appears that for normal invocations of `zig build`, it is safe to
assume that `@src.file` is absolute. However, when ZLS uses a custom
`build_runner.zig` to collect build configuration, `@src.file` is
actually relative to the current working directory, at least on my
system. For a while, this led to ZLS completions breaking entirely,
but presently it actually causes ZLS to crash!
The solution is not as simple as using relative `sdkPath` results
as-is, because the build system may attempt to resolve these paths
relative to build root, when the paths are actually relative to the
current working directory.
This leads to a sticky situation: the current working directory is a
runtime concept, but `@src.file` is resolved at compile time. However,
it appears that the build runner does not change current working
directory in between compilation and execution, so it is probably safe
to calculate `sdkPath` using runtime current working directory.
Still, this requires major changes with how `sdkPath` works, since
runtime computation and allocations are required. So pretty much
anything that relied on `sdkPath` being comptime-known has been
refactored in this commit.
The most severe result of this is that, for example, `gpu.pkg` can no
longer be a comptime-known constant: it has to be a runtime function
that takes a `*Builder` and returns a `Pkg`.
This commit deals with usages of `*.pkg` and `sdkPath` within Mach
itself, but projects that depend on Mach such as `mach-examples` will
almost certainly require changes as well.
* all: update README to reflect change in pkg usage
For details on updating your code to use this version, see: 88b1106953
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
Co-authored-by: Stephen Gutekanst <stephen@hexops.com>
* get column values from separate functions
* split ArchetypeStorage.block into blocks per component type
* ecs: remove allocator field from ArchetypeStorage
* ecs: remove whitespace
* ecs: correct suspicious index operation in setRow
* add back zero-size ColumnType check; bring back reliance on component names
* ecs: validate setRaw length matches
* ecs: fix failing test & move values slice into Column type
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
Co-authored-by: Stephen Gutekanst <stephen@hexops.com>
This reverts commit c3e05651bd.
Our M1 runner is not active right now due to the work going on with
Wrench, so this gpu-dawn version is missing macos-aarch64 builds at
the moment.
This allows the library to link better with projects. Otherwise you can end up with a mix of conflicts over that compiler + version to use.
Also adds .use_model3d option to mach build system. If set to true, model3d will be linked in statically to target project.
Since users of the library do not have access to the `@cImport` struct (and we
do not want to expose that), the user may pass only an untyped `*anyopaque` pointer
which we'll internally cast to `*c.GLFWwindow`.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
