Today I’ve began the experiment to add DBus support to JHBuild. To do this I’ve established these goals:
- Be able to launch JHBuild as a DBus service. Also test how can I set it up with DBus activation.
- Implement a list method, equivalent to jhbuild list command.
- Implement one of the build methods.
And guys, I did it! I’ve added a new dbus command to jhbuild to launch it as a DBus service, and begin to wait for user calls.And added a dbus frontend to buildscript. This frontend offers signals to know the status of a compilation (offering methods to get the logs, and to know the current status of compilation.
If I run:
dape@bonus:~$ dbus-send --print-reply --dest='org.gnome.JHBuild'/org/gnome/JHBuildObject org.gnome.JHBuildIFace.build
it launches a complete build. For example, I can use dbus-monitor to view events, and I get a log like this one:
signal sender=:1.95 -> dest=(null destination) interface=org.gnome.JHBuildIFace; member=end_phase_signalstring "libxml2" string "checkout" string "false"signal sender=:1.95 -> dest=(null destination) interface=org.gnome.JHBuildIFace; member=start_phase_signalstring "libxml2" string "build"signal sender=:1.95 -> dest=(null destination) interface=org.gnome.JHBuildIFace; member=message_signalstring "Building libxml2"signal sender=:1.95 -> dest=(null destination) interface=org.gnome.JHBuildIFace; member=message_signalstring "make all-recursive make[1]:se ingresa al directorio `/usr/local/devel/dape/cvs/libxml2'Making all in include
This way we can communicate with the JHBuild compilation loop. It should be interesting to avoid running jhbuild (and loading python) for each compilation in an integration loop. But it also adds an asynchronous channel to communicate with continuous integration tools. I’ll go on completing the dbus interface for most used commands of jhbuild tomorrow, and also add customizability (currently it does not wait for many kinds of parameters, it should be improved). When it’s more polished I’ll propose the patch for jhbuild.