The zig cache dir used to be specified as an absolute path because of an
issue with build processes for local subdependencies changing the
current working directory incorrectly, this has since been fixed.
Additionally %{builddir} is a new construct that is not available under
EPEL, %{_builddir}/%{?buildsubdir} was considered however there is no
need for an absolute path at this time.
The generated objects should never match on different architectures due
to how the cache system is designed however there this may cause
confusion while debugging so its been put under %{_vpath_builddir}.
Specifying a direct cache name would be possible however I think
_vpath_builddir has become pretty well known to maintainers and would
best be suited for this.
Zig depends on a C compiler (gcc for EPEL/fedora) during bootstraping
by transpiling itself to C then compiling that.
The C code that is generated runs into edge cases with
older gcc versions that triggers unique errors on more exotic hardware
such as RISC or ARM
changes to this need to be copied into zig-srpm-macros
docs fail to generate because the build runner is unable to find the zig lib directory, despite it being present.
it will be skipped for the initial build and included again once its figured out
this doesn't match how how we build other zig projects but it matches how stage3 is build using cmake.
I hope this brings the aarch64 memory usage down far enough for it to compile
the patch was originally introduced to fix some hash related issues where the artifacts created by zig may influence the hash creation.
This is only an issue when the build.zig.zon of a project specifies "" as a path, which means "include the whole project foler" including any sort of output or build cache.
While this hasn't caused any issues for anyone this is undesired behavior and changes how zig operates
its best to start a discussion with upstream how this best be dealt with
`zig build --system` fails if the given path does not exist
this hasn't been an issue for river or ghostty since they pull in dependencies which makes zig create the given path, but ncdu doesn't have any dependencies.
the summary flag outputs a complete build summary of the whole build tree output in an orderly tree structure, very useful for inspecting what the build system actually did
- zig does not handle relative paths passed to the first process so we need to specify an absolute path
- system integration was accidentally broken by an extra % sign
- system flag was used on cache instead of package directory
