Buck is Facebook’s super fast build system. How fast? Up to 7.5 times. That was intriging enough to get me to try it out, and immediately realizing that the platform is not complete.. One of the features missing is proper and complete support for Maven remote artifacts (aar and jar) and locally hosted Support Library artifacts.
Remote Maven Artifacts
So, Buck does support Maven artifacts in a rule called remote_file, which can fetch
files remotely, process them and make them available to the code-base. For example, if you want
you’ll create a
remote_file rule like this:
and depend on it in one of your targets:
aarif you want to fetch
This works, but wouldn’t it be easier and more friendly if you could import artifacts as easily as Gradle allows?
Based on zserge work, here’s a simple way to achieve exactly that. First, create a
DEFS file in your project’s root folder, and add
maven functions to it:
Second, import the
DEFS file to you project, but add the import code to the
This will make
maven rule available to every
BUCK file. So, now you can simply depend on the rule in your target, like this:
It doesn’t matter if the artifact is an AAR or a JAR, this
maven rule will fetch either!
The Support Library case
For some reason (legal? distribution?), the support library is not available in Maven Central
and instead, Google directly place it under your SDK folder (
[SDK folder root]/extras/android/m2repository/). That does not help the
prefix to find it.. The only safe way to make this work is by manually copying the
AAR file from there to a folder in your project
(Buck will not allow to reference a file outside the project’s folder structure).
First, add another rule to the
DEFS file we defined above:
Then copy the libraries you need in your project to a locale folder inside your project (lets say
libs). Create a
in that folder and import the support libraries:
Now you have targets you can depend on when creating Android app:
This is an amazing build platform! So fast, and so explicit to define and makes complete sense. The problem is that if you are to use it, you kinda giving up on Gradle, or any other (Bazel?) build system. The reason is that Facebook has its own idea of how an Android project is built, and how the relations between libraries and modules are defined. For example, you will not longer have resource merging, resource overwriting, or
R constant values. Aligning with Buck’s paradigm might turn out to be a very costly operation, and will definetly will not be compatible with Gradle, meaning you will not be able to run both build systems on the same codebase.