|
|
Boost Interest : |
From: troy d. straszheim (troy_at_[hidden])
Date: 2008-05-22 16:19:08
Doug Gregor wrote:
> On Thu, May 22, 2008 at 2:41 PM, troy d. straszheim <troy_at_[hidden]> wrote:
>> Doug Gregor wrote:
>
>>> Are they willing to accept patches that reduce the current level of
>>> coupling, and/or do some of this work? We can't do anything that would
>>> result in forking Bitten or taking over maintainership of major
>>> changes.
>> Understood, agreed. If it indeed turns out that bitten isn't easily refactored/patched,
>> how about putting something together that integrates *directly* with CTest.
>> Maybe the kitware guys would have some interest. I have to guess that I'm not the only one who
>> doesn't care for the java-Dart monolith.
>
> Kitware is building (and using) CDash, which integrates directly with CTest:
>
> http://www.cdash.org/
>
> Like Bitten, the CDash interface is totally wrong for a collection of
> libraries like Boost. We would have to do some serious interface
> upgrades either way.
Yeah. Egh.
> If Bitten doesn't work out, CDash is an alternative. I've done local
> setups of CDash with Boost-CMake submitting to it and it was
> relatively painless.
I cornered Christopher Lenz (bitten author) on IRC. He seemed amenable to decoupling stuff:
14:24 < cmlenz> I've wanted to decouple target platforms and build configs for some time, just
never got to it
14:24 < cmlenz> and decouple build recipes from build configs too, IIRC
14:24 < cmlenz> what's your suggestion about recipes/protocol?
we discussed briefly and agreed that the 'bitten as displayer of builds' model is different
than 'bitten as controller of slaves' and that integration wasn't straightforward. Then things
trailed off.
One thing occurred to me: (you'd have to have a bit of knowledge about bitten's code to get this)
the bitten server has direct local access to SVN. The build recipes could
be checked in. Testers with commit access (which could be access-controlled to this one area)
would have control over their own recipes. The total protocol/database changes to bitten
could be significantly fewer, and it would still work in controller-mode,
so the bitten guys (guy?) would have no reason not to adopt it. I'll try implementing this,
see what happens.
> But, I don't want to seriously propose it as an
> alternative until I've done a significant amount of work to improve
> the interface, because I *hate* when people throw out software
> suggestions without doing any work themselves :)
Having build results right there in trac is Really Slick,
and writing trac plugins (where all requirements are already present,
and the development, happily, is all pythonland) can't possibly be as
much work as dealing with all this stuff:
> [CDash] System requirements
>
> * MySQL database (5.x and higher)
> * PHP (5.0 recommended)
> * XSL module for PHP
> * cURL module for PHP (for site statistics)
> * GD module for PHP (for regression tests)
though I suppose I could be convinced otherwise.
-t