Zig Version
0.16.0-dev.1484+d0ba6642b
Steps to Reproduce and Observed Behavior
Running: zig build-exe idontexist.zig will emit a binary even if idontexist.zig doesn't exists
Expected Behavior
Don't emit the binary
0.16.0-dev.1484+d0ba6642b
Running: zig build-exe idontexist.zig will emit a binary even if idontexist.zig doesn't exists
Don't emit the binary
Not entirely sure if this is the linker's fault or the frontend's, so labeling as both.
I believe this is working as intended: our linkers are incremental, so will write to disk as soon as they start working, and the linker starts working pretty early in the pipeline, because while it waits for the Zig files to be processed it works on input link objects (including implicit ones like compiler_rt) and so on. But let's wait for @andrewrk to weigh in, just in case he had a design in mind to avoid this potentially confusing situation.
Even then, would anything actually prevent us from deleting the incomplete output file when the compilation fails, at least in non-incremental mode?
This issue makes zig compiler hard to integrate into build system, e.g. make-based one. When compilation fails for any reason, first run stops because of non-zero zig build-exe exit status. However, next run skips compilation step and goes further because target file already exists and is up to date. At best, build will fail later due to invalid ELF format. At worst, broken binary will be deployed.
Current workarounds are either to remove target on error in recipe, e.g. zig build-exe -femit-bin=$@ ... || $(RM) $@ && false, or to create empty stamp files to indicate recipe success and create dependencies on those stamp files.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?