Just a slower build. From ~20 seconds to ~65 seconds the first time after I nuke it.

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?

▲

Cloudef 5 hours ago | parent [-]

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.

▲

divan an hour ago | parent [-]

what exactly people call 'garbage collection' in Zig? build cache cleanup?

	▲	Cloudef 36 minutes ago \| parent [-]
		Indeed what was referred to here is the zig build system cache.

▲

sgt 5 hours ago | parent | prev [-]

Does Zig have incremental builds yet? Or is it 20 secs each time for your build.

▲

latch 5 hours ago | parent [-]

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.

	▲	sgt 5 hours ago \| parent [-]
		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.