Skip to content

builder: include more info in cache keys, derive inputs#5503

Draft
jakebailey wants to merge 3 commits into
tinygo-org:devfrom
jakebailey:gocacheprog-prep
Draft

builder: include more info in cache keys, derive inputs#5503
jakebailey wants to merge 3 commits into
tinygo-org:devfrom
jakebailey:gocacheprog-prep

Conversation

@jakebailey

@jakebailey jakebailey commented Jul 6, 2026

Copy link
Copy Markdown
Member

I've been working on a GOCACHEPROG implementation for tinygo, but am pulling stuff out of that branch.

One problem I hit in my stack (and, generally) is conditions where I am forced to delete my tinygo cache, usually because I switched branches or rebuilt LLVM. If I want to use a GOCACHEPROG that compresses stuff (my latest obsession), getting the cache key wrong isn't so great since the same cache is also shared by other stuff on my system and cleaning is one thing.

This stack attempts to fix a bunch of caching problems by including more stuff in the cache key, and make it so that when tinygo does some work that's going to be cached, it pulls that info from the cache key instead such that it's less likely to integrate other outside info (something something pure function).

Compute target library cache directories from a content-derived
description of the library build instead of relying on manual version
bumps. Use that same description to drive compilation, so the cache key
covers the inputs consumed by the build.

The key includes source hashes, generated headers, header inputs,
per-file flags, the compiler argument template, relevant target options,
and the clang/LLVM identity. This avoids stale lib.a and crt1.o files
after libc, compiler-rt, header, or compiler flag changes.
Stop caching C dependency lists as reusable inputs to object cache
lookups. Instead, ask Clang for the current dependency list before each
lookup and key the object by the current dependencies, compiler flags,
and clang/LLVM identity.

This avoids stale object hits when include path resolution changes, such
as when a new header is added earlier in an include path. It also avoids
using dependency data produced by a different clang binary.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant