-
I’m bringing my automated package builds up to speed, using only free infrastructure. That is:
Push commits to github -> triggers travis-ci builds
travis-ci sets up a Docker environment to build deb packages
Upload readily built packages to bintray.
The first project works at this point: https://github.com/tim-janik/rapicorn/
The second depends on the first and still needs work: https://github.com/tim-janik/beast/
Because the raw travis-ci environment is notoriously hard to debug, I’ve previously used pbuilder for the packages, but that’s still hard to deal with. Docker makes all this a breeze, it abstracts from the travis-ci tools and allows easy local rebuilds in case of failures. Also, simply exchanging the FROM line in the Dockerfile allows to trigger package builds for multiple distributions. bintray takes care of the package indexing and provides download space, so I can pass users a simple apt source line to test out development packages freshly built from source code that’s just been pushed 20 minutes ago.
-
We are revisiting versioning schemes for a GUI library and an audio synthesizer. Versioning ties in with package names in distributions, ABI guarantees, API breakage, versioned binary names to allow parallel installations of multiple releases and whatnot… And googeling on the net turns up a million contradictive opinions, from semver.org to “always use dates”.
Here is our current take on things, comments welcome: https://groups.google.com/forum/#!topic/rapicorn/M69DlAx61YE
-
Working on porting the object system in BEAST (music synthesis app) from GObject to IDL-based C++ classes. Quite laborious, given that an object system is ingrained so deeply into an app and library. But it’ll definitely be worth it once completed and allow new scripting facilities and a badly needed renovation of the GUI to match state of the art DAWs. I’ve summarized the beginning of the efforts in a recent DevLog: https://testbit.eu/rapicorn-idl-moving-into-beast/
-
I should have worked on a new Rapicorn release but instead cooked up a new IPC binding implementation. In the process I needed to use thread-local storage and did some benchmarking around TLS while I was at it. I’ve blogged about it here: https://testbit.eu/thread-local-storage-benchmark/
This week I’m trying to port the autotool machinery of the rapicorn project to meson and ninja to allow faster builds.
So far build times seem to be promising (though I’ve already been using ccache previously), but in particular the vastly improved configure times seem to be making things worthwhile.