builder: use build ID as cache key #2366
Conversation
|
Too bad we can't use Go's |
|
Yeah, I've so often wanted to use their internal packages. I wish they were importable somehow. Even if they don't provide API stability guarantees, having access to them would be great (for API stability, there is of course version pinning using Go modules). At the same time, by using GNU build IDs, I think we're also including all the non-Go code (LLVM mostly). |
|
Another option could be to take the hash of the executable. This is probably more expensive, but is portable. Hmm. . . nevermind it might be a bit too expensive. |
|
Not quite building yet on Windows: https://github.com/tinygo-org/tinygo/runs/4474797055?check_suite_focus=true#step:14:355 |
Instead of storing an increasing version number in relevant packages
(compiler.Version, interp.Version, cgo.Version, ...), read the build ID
from the currently running executable. This has several benefits:
* All changes relevant to the compiled packages are caught.
* No need to bump the version for each change to these packages.
This avoids merge conflicts.
* During development, `go install` is enough. No need to run
`tinygo clean` all the time.
Of course, the drawback is that it might be updated a bit more often
than necessary but I think the overall benefit is big.
Regular release users shouldn't see any difference. Because the tinygo
binary stays the same, the cache works well.
|
I think I've fixed the Windows failure. Let's see whether it passes CI. |
Yeah exactly, that was what I first wanted to do but didn't because it seemed unreasonably expensive. Luckily it's not necessary with build IDs :) Note that the latest push (to fix Windows) only uses the Go build ID, not the full binary build ID. I think that's not too big of a problem though. |
Instead of storing an increasing version number in relevant packages (compiler.Version, interp.Version, cgo.Version, ...), read the build ID from the currently running executable. This has several benefits:
go installis usually enough. No need to runtinygo cleanmost of the time.Of course, the drawback is that it might be updated a bit more often
than necessary but I think the overall benefit is big.
Regular release users shouldn't see any difference. Because the tinygo binary stays the same, the cache works well.
I made this PR mostly to make development for myself easier. I've been running
rm ~/.cache/tinygo/pkg-*far too often to clean the cache. Previously I just rantinygo cleanbut since #2110 that has become a lot more expensive.