Re: [Boost-cmake] Attn: Bitten hackers. Discussion about transforming CTest output format

From: Doug Gregor (doug.gregor_at_[hidden])
Date: 2008-05-22 10:19:30

Hi Troy,

On Thu, May 22, 2008 at 10:02 AM, troy d. straszheim
<troy_at_[hidden]> wrote:
> Quick-ish report on this:
>
> I spent several days hacking on bitten.  There are a few things that Dave and I discussed that
> need fixing.  It looks like the transformation of bitten from Build Controller to Build Result Displayer
> isn't trivial.

Hmm... that's unfortunate.

> Bitten is built with one way of doing things in mind:  the server controls everything.  The central
> (trac) server has a bunch of 'build configurations', which consist of an SVN url
> and a 'recipe' for building, and several associated 'target platforms', which are basically a tag
> and a few regexes to match things like OS and compiler version.   Target platforms are associated with
> one 'build configuration' and one build configuration only.
>
> This is nice (I guess) if you're adminstering your own group of build slaves, but not so good for us, as the
>
> - build recipe
> - svn URL
> - list of taret platforms
>
> are all tightly coupled.  One cannot, for instance, allow somebody to run and post serialization tests only
> on some obscure platform.   If I decided I wanted to continuously run a set of tests on the proto branch,
> I'd need a bitten admin to set up all kinds stuff...  if somebody else wanted to join in and test with an obscure
> compiler, the bitten admin would be involed again.  If you add a codebase to the rotation, you need
> to copy the target platforms and hack together a build recipe.  If somebody brings up a new platform,
> you need to add the description to all recipes that it will build.  And so on.

That sounds painful.

> I haven't yet thought about CTest, transforming CTest XML to bitten-palatable format,
> automatic generation of build/test recipes from cmake,
> or the possibility of some entirely different test-running mechanism than ctest.

I don't think we should look at different test-running mechanisms than
CTest. CTest integrates very nicely with CMake, and we don't have to
maintain it.

> For what I have been doing, dummy builds suffice.   I'm willing to switch to this though....
> We could decide for now to bear with the extra administrative overhead of the current bitten
> and focus on this stuff instead.  Comments?

I think it is much more important to continue working on decoupling
the masters and slaves a bit, because that's the fundamental part of
              Bitten that could give us trouble.

Have these issues been discussed with the Bitten developers at all?
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.

  - Doug