Quiet zig build progress bar output

When building with zig-build, the system outputs a huge stream of printouts to stderr (aka the progress bar) showing the build system’s traversal of the DAG. Is there a way to shut off that printout (short of 2 > /dev/null)? Just curious. My goal is to be able to do something like zig build --release=safe --summary all on a working program and to have the only printout be the summary at the end.

You can use a environment variable ZIG_PROGRESS to change desired stdio but I did not try it.

See also:

https://andrewkelley.me/post/zig-new-cli-progress-bar-explained.html

Thank you. I gave it a try with the command below (by pointing to a non-existent device number). It worked partially – i.e. some of the progress bar was eliminated. But overall, it didn’t work.

I guess it would be nice if there were a --quiet option on zig build that suppressed it more successfully. While in most cases the progress bar is helpful, there are cases where it results in thousands of lines on screen – which is not helpful.

Please let me know if you would like me to make this enhancement request via another method.

Thank you very much.

$ ZIG_PROGRESS=99 zig build --release=safe --summary all

Plus I failed to mention above. But the progress bar doesn’t work on Windows – hence my objection because I get thousands of lines rather than one continuously self-overwriting line. So this could also be considered a bug.

This should be filed as such on the issue board, please check first to see if it’s already tracked.

Your best bet is to replace the test runner, at the moment. I wrote ztap in order to generate TAP format from tests, you’re of course welcome to use it, but it’s also a good skeleton for adding your own custom test runner. It’s a fairly simple process.

Thank you. I filed Progress Bar "loses sync" under windows and spews 100's of lines · Issue #22055 · ziglang/zig · GitHub in the repo.

I’m not running tests. Just trying to avoid the progress bar when building / compiling.

1 Like

Custom build runners are also possible, but I think it’s safe to say that doing that is a bigger commitment than replacing the test runner.