Skip to content

Make zig-knowledge-graph build: no build.zig existed, and the imports pointed into another repository - #2

Merged
gHashTag merged 6 commits into
mainfrom
make-it-build
Aug 12, 2026
Merged

Make zig-knowledge-graph build: no build.zig existed, and the imports pointed into another repository#2
gHashTag merged 6 commits into
mainfrom
make-it-build

Conversation

@gHashTag

Copy link
Copy Markdown
Owner

This package could not be built or depended on by anybody:

Changes: a ZON manifest with a fingerprint, a build.zig exporting the library module and both executables with a per-root test target, the four imports repointed at the dependency, and a workflow that runs zig build and zig build test on 0.15.2.

The dependency is pinned to a commit, not to refs/heads/main. A URL pointing at a branch tarball plus a content hash invalidates itself on every upstream merge — which is exactly how the sibling package's pin came to be three versions stale, breaking at fetch before anything could compile and notice.

Local Zig here is 0.16 and reports failures that do not exist on the 0.15.2 target (std.io.getStdOut, ArrayList.init, the std.fs reorganisation), so I am letting CI be the instrument rather than editing code that is correct for the version it targets. If CI finds real defects underneath, they get fixed in a follow-up rather than guessed at here.

…mports

There was no build script at all, the manifest had no fingerprint and an
unhashed dependency, and the four imports pointed at files that live in
zig-golden-float — which imported this repository's knowledge_graph.zig
right back. Dependency pinned to a commit rather than main, because a
url-plus-hash against a moving branch invalidates itself on every merge.
Third time this class of mistake in one session — .zig-cache twice, now the
local package directory. The habit that prevents it is reading git status
before git add -A, not adding patterns after the fact.
Correction to the previous message: these are not artefacts of my local
0.16. CI on 0.15.2 reports the same errors, so they are real.
File.writer takes a buffer since 0.15; the tail of the file would not have
reached disk without an explicit flush, so save() would have reported
success on a file load() could not read.
Every call site discarded the returned count, so erroring on a short read
is the same contract the code already assumed.
@gHashTag
gHashTag merged commit 31aaaa1 into main Aug 12, 2026
2 checks passed
@gHashTag
gHashTag deleted the make-it-build branch August 12, 2026 07:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant