upvote
Just a slower build. From ~20 seconds to ~65 seconds the first time after I nuke it.
reply
But why is it so big in the first place?

I was searching around for causes and came across the following issues: https://github.com/ziglang/zig/issues/15358 which was moved to https://codeberg.org/ziglang/zig/issues/30193

The following quotes stand out

> zig's caching system is designed explicitly so that garbage collection could happen in one process simultaneously while the cache is being used by another process.

> I just ran WizTree to find out why my disk was full, and the zig cache for one project alone was like 140 GB.

> not only the .zig-cache directory in my projects, but the global zig cache directory which is caching various dependencies: I'm finding each week I have to clear both caches to prevent run-away disk space

Like what's going on? This doesn't seem normal at all. I also read somewhere that zig stores every version of your binary as well? Can you shed some light on why it works like this in zigland?

reply
AFAIK garbage collection is basically not implemented yet. I myself do `ZIG_LOCAL_CACHE_DIR=~/.cache/zig` so I only have to nuke single directory whenever I feel like it.
reply
what exactly people call 'garbage collection' in Zig? build cache cleanup?
reply
Indeed what was referred to here is the zig build system cache.
reply
Does Zig have incremental builds yet? Or is it 20 secs each time for your build.
reply
20 seconds each time. Last time I tried to enable incremental build, it wasn't working for us. It was a while ago, but I think it had to do with something in our v8 bridge.
reply
I have heard that from other Zig devs too. Must get a bit annoying as the project grows. But I guess it will be supported sooner or later.
reply