|
|
Boost Interest : |
From: David Abrahams (dave_at_[hidden])
Date: 2008-05-27 15:03:39
on Tue May 27 2008, "troy d. straszheim" <troy-AT-resophonic.com> wrote:
> 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.
Great!
> 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:
Absolutely.
> - We (http://www.icecube.wisc.edu) 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 trac-hacks.org, 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).
Awesome.
> 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
either.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com