Back in 2015, Google open-sourced its internal build system, Blaze, under the anagram name of Bazel. Since then I had worked to migrate and unify the various build scripts in my company into a single Bazel workspace.
Not long after, however, I decided that maintaining a Bazel workspace is not the best use of my time. I worked on other projects, and created an unrelated open source Bazel workspace for my own enjoyment.
This post will be a brief introduction of this project.
Why Bazel?
In one word, Hermeticity.
Well, Google engineers working on Bazel probably reinvented this word when it comes to building stuff. The word means that the building process is completely reproducible, regardless what environment you use. And by “completely reproducible”, we mean that the output binary stays completely the same, bit by bit. It also means no timestamps and fixed random seeds during compilation, but if they help you locate a really obscure bug, why not?
Since I am also a Gentoo user, there is something I dislike about this. I want to randomly update dependencies and see whether packages break or not. But for more serious projects, maybe a better reproducibility is desired.
Of course, by default Bazel uses the toolchain and libraries in your system. In this case, there is not much hermeticity to talk about, as people with a different system configuration will produce different results than you. However, as long as you do not update your system, your builds will at least be consistent, which is still something not easy to pull off in other build systems.
Other benefits include remote caching. However, while it has been in Google’s version of Blaze for years, last time I checked it was very hard to get Bazel to use that functionality. Hopefully things have improved since then.
Astraeus Workspace
Astraeus workspace is a much less ambitious project. I grabbed a few BUILD files from tensorflow and other open source projects, and wrote a few BUILD files myself.
Currently, the biggest applications buildable with this workspace are VIM and Inkscape.
There are also many dependent graphic libraries for Inkscape. Mostly because they are also dependencies of Tensorflow, supporting these is easier than other kinds of packages, which I usually have to manually write the BUILD files.
It can be found here.
What will happen next?
To be honest, I don’t know. Building stuff is too much chore, too little epiphany.
The event that triggered me to revisit Astraeus Workspace is that I discovered an Github issue opened in February. Alas, I have been neglecting Github for a few months. It turns out that Bazel itself is rapidly changing, and I should at least catch up.
Another long planned thing is to build a GCC toolchain with Bazel, then write a configuration for the toolchain. I am not sure what is the benefit, but that will make the little workspace an ecosystem on its own. This is the reason why I have been adding compiler libraries like gmp and binutils to the workspace, but progress has been very slow and I am not sure whether it can happen at all.
Another idea was to add a few random applications, then feed them to really nontraditional toolchains like Emscripten, and see what happens.