Using please.build as a repository orchestrator

Created on 2022-05-27T04:39:59-05:00

Return to the Index

This card can also be read via Gemini.

I did a little experiment using please.build to build various audio plugins for Linux. These tend to have particular requirements like doing git checkouts and possibly also checking out sub-modules, or downloading release tarballs, possibly applying patches so old plugins will build, dealing with dependencies with mixed versions that different plugins use, and they all have non-standard build or bundling requirements.

`please` worked fine for this. Although my build scripts are a bit stupid--they just download the exact version of things a plugin wants and use a shim blank script to do nothing with them. Then we have a job that makes sure to move them wherever the plugin vendored it. And we build packages by just calling whatever build system that plugin natively uses.

Something to note is that being a [Bazel](https://bazel.build/) clone it really wants to be the one performing the build steps as well. So one feature we have to short circuit is one that kills stuck builds after a timeout. Sometimes running a build can take more than ten minutes and `please` will see this as a stuck job and kill it. Other than that it actually works pretty well.

Note though that I am not really playing in to the strengths of a Bazel system with this. It's basically just used to coordinate downloading a bunch of files and compiling them normally. A "proper" build script would take over the build jobs from software like Meson and CMake so we were never wasting any time with CPU idleness or could even use the remote job tools to scatter build jobs across a datacenter.

I may play around with Gnome's [JHBuild](https://gnome.pages.gitlab.gnome.org/jhbuild) next. It's closer to what I am actually doing here and it's worth taking a short peek. Another alternative I'm looking at is building plugins via Flatpak.