Open cr0sh opened 1 year ago
Would call it, mismatching steps on build.zig or something?
zig mantainers shouldn't wor about package breakage, but the error itself is weird
zig build run
with 0.11.0-dev.2986+012f9a97e
Likely introduced by https://github.com/ziglang/zig/pull/14872 as unintended side effect (I did not bisect this).
re-tried with 0.11.0-dev.3000+d71a43ec2
and got the same error as well. was not able to repro title issue
@nektro What platform are you testing on? I'm on MacOS aarch64 13.3.1a(Ventura), and zig build run
downloads the module without any issue.
I removed ~/.cache
and zig-cache
to ensure the modules are freshly downloaded, but correct me if I'm wrong.
I'm on Linux x86_64, NixOS 22.11 in particular
Hmm that differs. I think we should wait for https://github.com/ziglang/zig/issues/15590 to be resolved first?
Still fails on 0.11.0-dev.3262+df909da5d
. Updated the instructions.
(FYI the getty maintainer temporarily removed the 'clean' step on the latest master, so you may not reproduce the issue correctly if used)
Note that it should be perfectly fine for any packages to have same-named top level steps, since they each have an independent top level step namespace. There is something a bit more subtle and tricky going on here.
As a first step, we can collect a stack trace where a top level step is defined, and then print it when such a conflict occurs. That will make for a nicer debugging experience, no matter what the root cause of this ends up being.
Zig Version
0.11.0-dev.3262+df909da5d
Steps to Reproduce and Observed Behavior
(Steps taken from https://github.com/getty-zig/getty#quick-start)
zig init-exe
Replace build.zig with
For some context,
getty-zig/json
depends ongetty-zig/getty
, and both package defines a step named"clean"
, which would be a trouble.Expected Behavior
Compiliation succeeds on
0.11.0-dev.2563+35f9c8444
, so it could be affected by a breaking change.