|
|
Boost Interest : |
From: troy d. straszheim (troy_at_[hidden])
Date: 2008-05-22 10:02:46
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.
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.
This coupling touches just about every part of the code. The build progress display
(i.e. 7 of 16 steps completed with a little progress bar) depends on the server knowing
how many total steps are in the recipe that the client is building. In the Bitten Way, the
server does know because it sent the recipe to the client in the first place.
What Dave and I discussed was bitten with less Control and more Display. If clients are to be allowed
to formulate their own recipes, the protocol and database need changing (clients need to report the recipe,
at some point, along with "Here are the results for step 7 of that recipe that I said I was working on".)
I got this much of it done as part of just learning to hack on trac plugins, then noticed that the queueing
logic will need modification, as well as the association between platforms and urls/recipes...
it looks like basically a rewrite.
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.
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?
-t
Doug Gregor wrote:
> There's a (short) discussion on the CMake list about transforming the
> XML output of CTest into a different format:
>
> http://www.cmake.org/pipermail/cmake/2008-May/021782.html
>
> They're talking about translation into an Ant-friendly format, but
> this is exactly what we'll need to do to translate CTest's output into
> something that Bitten can grok.
>
> - Doug
> _______________________________________________
> Boost-cmake mailing list
> Boost-cmake_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-cmake