Using bazel to build hubris instead of cargo

[cbrune]

Hi All,

First off, thanks Oxide for creating hubris and sharing it with the world. You did not have to, but I am glad you did.

At Enfabrica we are considering to use hubris on an ASIC we are building. Internally we use bazel to build everything. TL;DR - bazel does not use cargo to build rust programs, but hermetically manages dependencies itself and calls rustc directly. That statement should either fill one with terror or joy -- I myself, feel both, often several times a day.

Please do not start a cargo v. bazel flame war. That is not why I'm here.

I have taken a rather deep tour of a hubris build using bazel to see what is what. The main sticky part naturally is xtask dist.

I gather bazel support is not super interesting from Oxide's perspective, which makes perfect sense. You got things to do and time is of the essence.

I am, however, curious if anyone else would be interested in such a thing?

Outside of full on bazel support, I wonder if patches would be considered that "refactor" xtask a bit. In short, making xtask more of a library than an executable.

In my investigations I see two main refactoring patterns on the road to bazel:

1. A handful of places in xtask use hard coded file system paths for build products. For example several things are in target/..... A minor refactor for these cases would be to introduce functions that take the output path as an argument.
2. Separating the generation of intermediate configuration from rustc compiling and linking.

More words for the 2nd point -- a number of xtask dist functions perform two logical steps:

1. based on some inputs, compute some things, and emit some intermediate file, like a linker script fragment.
2. run the linker on a target using the outputs from step 1. I used the linker script example, but other cases exist that follow a similar pattern.

In a bazel world those two steps would need to be separate steps of the build. The refactor in this case would be to take a function like link_task() and refactor it into two functions, one that generates the linker script and one that performs the link.

I hope this example explains what I mean by making xtask more of a library than an executable.