[Boost-cmake] dart as trac plugin

From: troy d. straszheim (troy_at_[hidden])
Date: 2008-05-27 12:40:04

David Abrahams wrote in "[boost] Release Tools Analysis Part II":
(http://lists.boost.org/Archives/boost/2007/08/125724.php)
[snip]
> In my conversations with
> the Kitware guys, when we've discussed how Dart could accomodate
> Boost's needs, I've repeatedly pushed them in the direction of
> rebuilding Dart as a Trac plugin, but I don't think they "get it" yet.

I'm wondering what the current thinking is on this.  I independently
came to the same conclusions (some time ago) and started working on it (last week).
I have a trac plugin that receives ctest's xml-rpc calls, unpacks the XML,
and puts the data in the database  (working title:  'traash' == trac + dash).
There is a bit more work to do on this 'ingestion' phase, and then there
is the display of the results.  I expect to have
something actually displaying build results in slick fashion by the end of the
week, maybe early next week.  Depends on how much time I spend writing emails like this :)
It has been slow going at first, as there has been a lot to learn about
how ctest works, including some painful reverse engineering,
and a bunch of nitty-gritty to learn about writing trac plugins,
but at this point I've got good momentum.

I'm thinking that there are a number of specific advantages to this approach:

- the model is simple.  You ingest ctest's xml into the database, then
   any view of the data that you want to hack together, you can.

- There is no queueing business to worry about.  CTest does that already,
   directly from svn.  The ctest client knows what it built last and takes care
   of deciding when to rebuild.

- The 'recipe' is naturally on the client, and we've already built the slave configuration
   infrastructure:  you configure your build slave simply via the existing cmake options
   BUILD_WHATEVER and TEST_WHATEVER.   As a consequence, complicated slave-runner scripts
   should not be necessary.

- The plugin will work with anything built/submitted by ctest.  There is nothing
   boost specific.  I'm sure we're not the only ones who would be interested in
   this, in part because:

- We (http://www.icecube.wisc.edu) need this too... I have to write it anyway.
   We're losing sysadmin-hours on restarting dart servers.

- It seems inevitable that some community of users would pop up around this.
   Maybe the kitware guys would be interested in it once they
   see how fundamentally slick the trac integration is.  (Though until they switch from
   cvs+mantis to svn+trac, it might continue to be hard for them to 'get it')

- There is no lock-in for boost.  A future switch to a tweaked cdash, or whatever,
   could occur basically just by changing some urls.  The development could proceed
   in parallel with the other approach (which I'm gathering is a couple of bitten
   hacks, plus xsl transforms of ctest output and client scripts).

I realize that there is well-founded hesitation about inventing things that we'll need
to maintain.  I'm OK with a thanks-but-no-thanks (if so, forget I mentioned it,
and I'll be glad to assist with bitten hacks, I'm getting pretty good with these trac
plugins.)

-t