Boost logo

Boost Interest :

From: David Abrahams (dave_at_[hidden])
Date: 2008-05-30 13:17:30

on Thu May 29 2008, "troy d. straszheim" <> wrote:

> David Abrahams wrote:
>> on Tue May 27 2008, "troy d. straszheim" <> wrote:
>>> David Abrahams wrote:
>>>>> - 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?
>>> Well once the build results are in the database, I guess it isn't so different,
>>> but again the bitten server keeps track of
>>> which builds/recipes were doled out to which platform at which
>>> revision.
>> I think we'd want to track that, too, no? We don't want two identical
>> slaves to do the same work... which brings up the fact that we haven't
>> really considered resource usage well yet.
>> * build/test responsibility ought to be split among multiple slaves
>> with the same configuration when they're available.
>> * multiple slaves with a shared disk should be able to share
>> repository revision images. This is especially important for me,
>> as I'm running VMs to test on a multicore machine.
> CTest doesn't do any of this out-of-the-box. For the first I think you
> just need to get a customization hook into ctest's 'should I build now'
> logic, perhaps to do some additional local
> step once you have determined the svn repo's revision. I'll give it
> some thought.

I was thinking of building the second feature as a standalone python
component. It should be relatively easy to manage a number of such repo
versions at the same time.

>>> It also knows which builds are pending, how many steps each contains,
>>> etc.
>> Don't we want to know that stuff? I do!
> Yeah, definitely. CTest does some of this but with mediocre resolution:
> it just reports Configure/Build/Test, after they happen.
> On this one I think the design is pretty easy, you add
> a command to ctest to submit the list of pending tests (this list is indeed
> available in files called 'CTestTestfile.cmake' after the build is configured
> and this is probably easy to get at from within ctest.) That will do for the
> tests; for the build steps, probably you can create some targets
> inside the boost_add_library(), etc macros that just print what is
> going to get built. Then you'd submit via a custom submit hook or somesuch.

Sounds like you know enough about what's going on in there to implement

>>> There's a lot of state there, and the code is tangly. None of that
>>> applies to the traash/ctest/dart model, where the client decides to
>>> build by consulting svn directly, and the server simply ingests build
>>> results as they arrive. Anyhow, I guess we can let this die now.
>> Naw, let's shake it a little more.
> Ok, so the ctest client consults svn directly, does not tell the dart
> server what it is going to do: simpler model, easier to Implement
> Right Now, but missing functionality as above.

Maybe we should pursue both tracks in parallel until we discover which
one will be easiest?

Dave Abrahams
BoostPro Computing

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