Hi I got a question today from the build masters for another product at my client. They are currently using Maven for their Java builds but are considering to move to BUCK. When I read about the features of BUCK, one thing that struck me was the cache function. When having 100+ developers working on the same codebase, such a function may readlly speed up development. Have you considered this type of functionality?
From http://facebook.github.io/buck/concept/what_makes_buck_so_fast.html: ‘That way, when a developer syncs to a revision that has already been built on your CI system, running buck build should not build anything locally, as all outputs should be able to be pulled from the cache. This works because the cache key computed by Buck when run on the CI system should match the key computed by Buck on your local machine.’
Thanks for the feedback. Yep Buck and Gradle are similar in that the both track inputs and outputs to a “task” and use the previous outputs if none of the inputs have changed.
One nice thing about Buck is that the cache of ‘previous outputs’ is shared between developers (and CI), whereas in Gradle it’s local to the current machine. This is definitely something we have plans for in Gradle, as part of our ongoing improvements to performance and scalability.
The main performance driver for buck seems not the global sharing of caches, but having a persistent cache of multiple builds, that is outside the scope of cleaning. So for “buck build; buck clean; buck build;”, buck will still find the cached result. And it does not cache just one results, but as many as the cache size allows, also of different filesystem states. How difficult would it be to write a gradle plugin that implements such a cache. I.e. how difficult would it be to wrap all tasks in a project such that a custom cache lookup could replace actually running the task?