Building with Bazel

Episode 5 - Meet the Sample Projects

In the last episode, we built a very simple Java app. It consisted of one class and no other dependencies. There were no tests. In reality, projects tend to be have a little complexity so we are going to leave our simple Java project for now, and rather turn to an app that we use to teach the basics of iOS and Android development. This is a simple game that was written for both iOS and Android. This app has both a native Kotlin version and a native Swift version. Our task in the next series of episodes is to switch both of these apps from their native build tools into Bazel. This is going to take some time so before we write our custom workspace and build files, lets take a walkthrough of these apps to see what we are working.

Demo

To get started, we’re going download the starter project for this episode. Open the Bullseye iOS app in Xcode. This is an app written in SwiftUI that contains a bunch of different views. Build and run the app. You’ll see a slider. We have to slide the slider thumb to where we think the target number is located. The closer to the target, the more points are earned. It’s a pretty simple game. Back to the app, while there are no dependencies, this iOS version of the app is also comes with a few unit tests. So our goal is to get this to compile with bazel as well as create a target that will run the unit tests. We’re dealing with multiple source files as well as our info.plist as well as our app resources like icons and so forth. Now this is a SwiftUI app. Now Bazel doesn’t provide swift or kotlin support. But Bazel was designed from the ground up to be customizable and extensible. Bazel maintains scores of repositories that provide rules for compiling a vast wealth of languages and platforms maintained by the community. And if the rules don’t exist for a particular language, Bazel provides all the tools necessary for you to custom build them so if you are working with a really niche language or toolset, you can get Bazel to work with it.

Now, let’s open the Android version of the app in Android Studio. This is the same app except its a native Android app. Let’s build and run. And you’ll see that it looks and behaves just like the iOS version of the app. Looking at the app code, you’ll see that it is written with the Kotlin language. We’ll import the Kotlin rules to get it to compile.

Unlike the Swift version, this version does not contain any unit tests. But it does contain something that Swift version doesn’t have. And that’s dependencies. Open up the module build.gradle file, you’ll see that we have lots of dependencies that we need to include in order for this build compile.

Finally, you’ll notice that these sample projects are contained in two different repositories. One of the advantages of working with Bazel is that instead of storing all this code in multiple repositories, we can store it all in one repository called a mono repository. To find out why we would actually do such a thing, then meet in next the episode.