Created attachment 69483 [details] [review]
This patch adds a dbus frontend to jhbuild.

To run the jhbuild as a dbus frontend you have to execute "jhbuild dbus". It starts a loop waiting for dbus calls.

I added the following DBus interfaces:
   * dict:string,dict:string,string info (array:string modulelist): returns the information about the modules requested.
   * array:struct:string,string list (array:string modulelist): returns the list of required dependencies required to compile the module list.
   * async update (array:string modulelist, array:string skiplist, string start, string datespec): updates the modules in modulelist and their dependencies, starting in start parameter, ignoring the modules in skiplist. The checkouts will be obtained using the datespec.
   * async updateone (array:string modulelist, string datespec): updates the modules in modulelist. The checkouts will be obtained using the datespec.
   * async build (array:string modulelist, array:string skiplist, string start, string datespec, dict:string,string options): builds the modules in modulelist and their dependencies, starting in start parameter, ignoring the modules in skiplist. The checkouts will be obtained using the datespec. The options parameter is a dictionary of additional options. They can be autogen (forces autogen.sh of the module), clean (calls make clean before compiling the modules) and nonetwork (forces avoiding access to network, and then, avoids accessing version control repositories).
   * async buildone (array:string modulelist, string datespec, dict:string,string options): builds the modules in modulelist. The checkouts will be obtained using the datespec. The options work in the same way as in build command.
   * void set_autogen(boolean enabled): set the global autogen parameter value. If set, it will run always autogen.sh before compiling modules.
   * boolean get_autogen(): obtains the current global autogen parameter value.
   * void set_clean(boolean enabled): set the global makeclean parameter value. If set, it will run always run make clean before compiling modules.
   * boolean get_clean(): obtains the current global autogen parameter value.
   * void set_nonetwork(boolean enabled): set the global nonetwork parameter value. If set, it will run always avoid networks access (and checkouts) for build and buildone commands.
   * boolean get_nonetwork(): obtains the current global nonetwork parameter value.
   * struct:string,string,string get_status(): obtains the current compilation status. The struct has three fields: the current command (build, buildone, updateone, update), the current module, and the status/phase (idle, build, checkout, …).

You can hook to the following signals:
   * start_build_signal (): called when a build starts.
   * end_build_signal (array:string failures):called when the build ends. failures contains the list of modules that did fail.
   * start_module_signal (string module): called when a module build starts. module contains the name of the module.
   * end_module_signal (string module, boolean failed): called when a module build ends. module contains the name of the module. failed tells if the module build has failed.
   * start_phase_signal (string module, string state): called when a phase in the build of a module begins. module contains the name of the module. state contains the name of the phase.
   * end_phase_signal (string module, string state, boolean failed): called when a phase in the build of a module ends.module contains the name of the module. state contains the name of the phase. failed tells if the build phase has failed.
   * message (string message): all the messages from compilation logs are sent through this signal. If you want to retrieve the compilation log, you should hook and get all this messages. This signal is called in each phase with a frequency of 5 seconds.

Would you care to elaborate on what you want to use this interface for?  It is a bit difficult to review such a patch without that information.

(In reply to comment #2)
> Would you care to elaborate on what you want to use this interface for?  It is
> a bit difficult to review such a patch without that information.

In continuous integration tools like tinderbox or buildbot, we usually require (in order of importance, first is most):
1. A way to request compiling and know the process end status. For example, we build gtk and we want to know if the build has failed. Of course, in an environment like jhbuild we need to specify which module we want to compile.
2. A way to get the compilation log after the build, in order to publish it.

But, if we want to provide real time information of the compilation status, we would require more:
3. A way to get the current log (preferrable to get the log on an incremental method).
4. A way to know the stage it's currently running (best is most accurate).

For example, in a tinderbox environment, we want to compile all the gnome 2.16 daily.
   * It will retrieve the modules in the required order using jhbuild list.
   * Then it begins a loop to compile all the modules using jhbuild buildone <module>. It gets the logs and parses them to retrieve the errors and know the step it's running or the step it has failed.
   * These logs and status are published in a webpage, and through rss, in order to let the developer know the build status of the projects he's involved.

Other use cases would involve getting information about each modules (to be published in the tinderbox webpage).

With dbus I get a better way to communicate with the jhbuild builder, taking advantage of the buildscript class hooks. It also provides a way to reuse the same python vm among different jhbuild calls.

Note: when I talk about tinderbox I mean Mozilla tinderbox.

Jose, is this patch still necessary for the buildbot work ?  Otherwise I will mark this bug report as obsolete.

Marking bug as obsolete; please feel free to reopen if needed.