20% Project 1 - Bazel my PhD
During the course of my PhD I have found I tend to flip flop between periods of intense work output, followed by 1-2 weeks in which I work on very little, or something unrelated to my research. In an effort to rebalance and achieve a more consistent work output, I’m trialing ‘20% time’ for the next month. The goal is to take one day a week to solve (or make a resonable stab at) a problem related to my PhD, unburdened by the demand for scientific intrigue.
Today was the first of my 20% projects, and I used the opportunity to tick off two items which had been on my TODO list for over 6 months: overhaul the jumble of files in ~/phd, and learn the basics of the Bazel build system.
I use a single repository to track all of the work for my PhD, with the idea being that at any time and on any machine, I am only two commands away from having a clean ~/phd from which I can work on anything. The build system for ~/phd must be flexible enough to handle a range of different targets (C/C++ libraries, LaTeX documents, python test suites) and dependencies (I build my own toolchain and all libraries from source). My solution for this was what I will politely brand as an “artisinal, hand crafted” Makefile, with an unwieldy dependency graph. Compiling a C binary requires tracking back all the way through a local clang build to a cached tarball of the LLVM source.
My build the universe single-repository Makefile was, for a short period of time, fully featured and a beauty to behold. However, with the unstructured and ‘everything is global’ nature of GNU Make, it quickly became unmaintable, if for no other reason than the ongoing challenge of coming up with unique variable names. The two obvious candidates for replacements (autotools and cmake) were ruled out on the grounds of common taste and decency. I was in the market for the a new build system, and Bazel seemed the perfect candidate.
I had become somewhat enamoured with Bazel since a talk at 2015’s Google Compiler summit in Munich. The combination of Google’s monolithic repository and a modern toolchain (which hopefully wouldn’t have me writing any more m4) placed it in pole position for ~/phd/Makefile replacement, but for lack of time and will, I didn’t get around to starting on it until today.
While a single day is far too short a time to become comfortable with a new tool, it was sufficient for me to implement a mostly feature-complete Bazel-ification of the old build system; and, most importantly, I am once more only two commands away from ~/phd anwhere, making this is a successful first inning for 20% time.