Continuing to talk about Facebook’s build tool, Buck, I’ll first go through some issues I faced while following the Getting Started tutorial from Facebook. No need to suffer alone, eh?!
Then, I’m gonna talk about the main files, build rules, and some specificities of the Airbnb fork. And that’s because, at my company, we based our fork on theirs. They have been very open to the community and are publishing updates more often on the open-sourced repo.
Getting Started Tutorial
I already have all the dependencies installed, but I remember running into some issues with Java8 and Watchman, of course Stack Overflow saved me 🙏
However, I went through building the example app recently, and I faced some errors with the project’s tests. The repo is really outdated and there wasn’t a very good response about it on slack. Honestly, I didn’t go really deep in the research for that cause the Airbnb’s sample will be more useful for us.
Before we move on, just a quick tip, something that will likely happen and how to fix it:
Usually it can be solved with the following command, but you can also check this thread:
Building buck locally
If you wanna play around with Buck, building it locally will be needed.
Once you get to building buck, read the output. The command/paths you need to run/use might be slightly different from the suggested in the tutorial.
After successfully building buck, you can give a try on Facebook’s samples.
Airbnb’s Sample App
Airbnb’s repo has some alterations on their buck’s fork. They have added a few aliases, scripts and other cool stuff to make it easier to use the build tool.
All this scripts are under
/Makefile. Check it out for more details.
To run their sample app, you would need to clone the repo, move to the root folder, and install buck locally, then add the correct files to the sample project. But because they are awesome people, all you need to do is run:
Run project from terminal
After running it, you can see a unix executable created in the /tools folder. Every time you invoke a buck command (like buck build), that’s what will be used.
Next, run the following command to run the project from the terminal.
You might get an error with some library linking issues. I went to buck’s slack and the resolution is to append
-L/usr/lib/swiftat the end of
ldflagsin the file
Run project from Xcode
If you want to create a Xcode project and debug it from there, use the command below.
At my company, we mostly use this option, except for CI. We still get the benefits of using the IDE and it’s easier for developers.
Diving into the buck files
Okay. Here’s where the journey starts. I’m gonna say again, I’m still learning to use the tool, when trying to create new things the documentation might not be enough, errors and problems seem to be very unique and sometimes it’s absolutely frustrating.
BUUUUUUUT, it’s a very powerful tool and you learn A LOT along the way.
First and foremost, every Buck project must have this file at the root. This is where you’ll define your customizations. According to the Facebook:
.buckconfigfile uses the INI file format. That is, it is divided into sections where each section contains a collection of key names and key values
For example, choosing swift and iOS versions, enabling python parser for BUCK files, choosing Xcode as the IDE and optimization flags. In the file, they would look more and less like this:
If you want to deepen your knowledge on it, check the documentation.
As said before, Airbnb did some tweaks on Buck’s functionalities. This file contains macros with custom behaviours. For instance, to create libraries, we will use
first_party_library which will already create a
apple_library target with the source files, a
apple_test target and an additional target for CI tests.
.bzlstands for “Build Zebeline Language”, which is apparently a very sympathetic mammal (if admired from far).
BUCK build files
You can still use Python by setting the config
polyglot_parsing_enabledI’ve mentioned in the previous topic
Let’s break down Airbnb Sample’s file in the path
./App/BUCK to exemplify what each rule means.
You can use definitions of other files by using load(_: , _:). The first argument being the name of the file and the next ones the properties/functions.
Assets can be declared using the build rule
Libraries that we usually add to a project using Carthage or Cocoapods have different build rules depending on how they’re shipped. We can talk about this later. One exemple, though, is AFNetworking, used in the sample app.
You probably use a build script like Swiftgen. Pre and post-build scripts can be declared using
Defining the app has a few steps. Defining the library, bundle, binary, and the package.
To use Xcode, we need to define a workspace that will later be called when running
HOLY COW! Wasn’t that a good start?!
I hope you were able to follow the explanations and the structures are a bit clearer now. If you have any doubts, reach me on twitter!
Next, we are going to see external dependencies, so get ready.