That seems really useful, but how is this different from what ccache and various other compilation caches that cache things as a function of their input do?
The GP talks about "build system integration" being "a game changer", and I can see that being a useful thing for e.g. "priming" your cache, but that's surely just a matter of say:
ccache-like-tool --prime $(git rev-parse HEAD:)
I.e. give it an arbitrary "root" key and it would pre-download the cached assets for that given key, in this case the key is git-specific, but it could also be a:
> how is this different from what ccache and various other compilation caches that cache things as a function of their input do?
Vertical integration, basically. There is value in these things working, and working well. As an example of the issues with ccache etc, I've yet to find a compilation cache that works well on windows for large projects.
I've never worked on a project with a large remote ccache but I would guess it would be pretty much the same yes.
The "automation" of our in-house system is what really makes the difference but then again we have a team of developers that focus on tooling so it's not so much automated as it is maintained...
The GP talks about "build system integration" being "a game changer", and I can see that being a useful thing for e.g. "priming" your cache, but that's surely just a matter of say:
I.e. give it an arbitrary "root" key and it would pre-download the cached assets for that given key, in this case the key is git-specific, but it could also be a: Or whatever.