#Why is zig-cache so large?

1 messages · Page 1 of 1 (latest)

cloud oasis
#

How do people manage this? I don`t have enough space on my laptop to have projects randomly taking up 50Gb all over the place. Do you just regularly delete it?

image.png
sterile vigil
#

zig doesn’t currently delete any cached items, you’re responsible for deleting it every so often

cloud oasis
#

So how do people handle this normally? a script to do daily deletes of the cache folder? make the build.zig cleanupy after a build?

torn swan
#

just kinda don't handle it

#

i delete it sometimes

flat stag
#

you can write a program that will delete cache files whose read timestamps have not been updated for a certain period of time

cloud oasis
#

Thanks, yea, for me I hate having to remember to clean up things intermittently.

#

I guess I need a clean.sh or make clean setup then.

amber saddle
cloud oasis
#

haha, yea, it wouldnt matter so much but over 6 different zig projects it adds up just a bit 🙂

fringe atlas
#

I manage this by not using the zig build system 😄
Then the cache folder somehow doesn't grow.
Has also a couple of further perks.

#

Otherwise (if I have to), I manually delete the folder (once or more times a day). Very annoying.

brisk hemlock
#

this is from 0.13.0, idk if something needs to be changed for 0.14.0

cloud oasis
amber saddle
#

Why are all answers on this thread about using GNU make, don't people realise that the Zig build system precisely attempts to replace GNU make?

#

Also CMake is the literal devil, don't let me get started

cloud oasis
#

Heh, thats literally the point of my question. How do you stop that folder building up. As for CMake, well yea, it seems horrible.

fringe atlas
#

I feel there's some kind of issue with detection of changes. Without using build.zig (that is by using zig build-exe directly) the cache folder doesn't grow, but pretty often zig starts rebuilding the std and I'm almost sure this also happens without any changes to the program's source code whatsoever (I just never found time to verify that to 100%). It seems to happen if the computer went to sleep in between and I think in some other cases too. With build-exe this merely means an unnecessary increase in compilation times, as it seems to overwrite the same cache files (I guess). My theory is that with build.zig in the same situation it might be creating new cache files without deleting the old ones. My impression is that the amount of "unnecessary" std recompilations observed per day matches in the order of magnitude the growth speed of the cache folder. Just a theory, FWIW.

amber saddle
#

Std is bloated, give up std

flat stag
#

And compiler in this case don't overwrite cache files, i check timestamps

torn swan
#

it's not a bug, there is no garbage collection done at the moment

flat stag
rich jacinth
#

i just occasionally go "oh it's been a week or two" and delete it

#

oops i was somehow seeing really old history

#

discord failed to scroll me

rich jacinth
#

but like, if you have reason to believe there is, open an issue

#

don't just assume we know about bugs

brisk hemlock
#

Right, doesn't sound like bug. Cache files shouldn't be overwritten - they are identified by content hash thus for all means and purposes immutable. Though cache getting filled up with slightly different compilations of std does seem weird

rich jacinth
#

That isn't true; ZIR caches and cache manifests do not incorporate file hashes to decide their names. Instead they store the stat and hash in the file contents (well, ZIR doesn't store the hash since there's not really much point in hashing the file compared to just redoing AstGen)

flat stag
#

Else add about AST Lowering
When this process doing in bug meaning, zig create child process:

cc -E -Wp,-v -xc /dev/null
cc1 -E quiet -v /dev/null -mtune=generic -march=x86-64 dumpbase null

although during the build I don't even run the C compiler