Boost logo

Boost Interest :

From: David Abrahams (dave_at_[hidden])
Date: 2008-05-27 15:03:39

on Tue May 27 2008, "troy d. straszheim" <> wrote:

> David Abrahams wrote in "[boost] Release Tools Analysis Part II":
> (
> [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.

Not so different from the bitten model, is it?

> - 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.

Fine by me.

> - 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.

That's a huge advantage.

> - 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 ( need this too... I have to write it anyway.
> We're losing sysadmin-hours on restarting dart servers.

In that case I think such a plugin could fairly be classified as "not
maintained by Boost." Since we know it would be built to serve Boost's
needs from the ground up, I think it's preferable to go that way than to
try to modify Bitten.

> - 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')

Their loss. However, if you publish this thing on, it
*will* gain a user community.

> - 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.)

No, let's do this. I've never understood what the big deal about
modifying Bitten is, in part because I think what it does is so damn
simple, so I don't think starting from scratch is particularly hard

Dave Abrahams
BoostPro Computing

Boost-cmake list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at