Commit graph

8 commits

Author SHA1 Message Date
Stephen Gutekanst
6bd4d91932 all: cache module() returns to avoid duplicate modules
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
2023-03-15 21:20:28 -07:00
Stephen Gutekanst
ddb728d74d gamemode: update to latest Zig build API
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
2023-02-12 10:05:03 -07:00
Ali Chraghi
9675bd662e gamemode: fix package path 2023-01-12 01:54:48 -07:00
Stephen Gutekanst
a750e31d11 Revert "all: build: fix sdkPath for relative @src.file / fix autocompletion with ZLS / IDEs (#661)"
This reverts commit a1fe671db8.

Lue suggested reverting #661 because ZLS worked around the issue of @src
being relative in that environment: https://github.com/zigtools/zls/pull/898

This is not a perfect solution (what zls did seems to be a workaround), but
is good enough for us until Zig gets an official package manager.
2023-01-10 01:57:52 -07:00
Lue
a1fe671db8
all: build: fix sdkPath for relative @src.file / fix autocompletion with ZLS / IDEs (#661)
* 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>
2023-01-02 01:23:46 -07:00
Ali Chraghi
82e10f4f28
all: build: thisDir improvements (#570)
* build:all: thisDir improvements

more performant output, usage code reducement and compileError for wrong usage

* glfw: update deprecated code
2022-09-29 08:41:46 -07:00
LeRoyce Pearson
a8d8fedf95
gamemode: addIncludeDir -> addIncludePath (#569) 2022-09-26 19:57:46 -07:00
Ali Chraghi
2ab3516795 gamemode: use zig build 2022-09-18 17:09:54 -07:00