Re: [Boost-cmake] dart as trac plugin

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

on Thu May 29 2008, "troy d. straszheim" <troy-AT-resophonic.com> wrote:

> David Abrahams wrote:
>> on Tue May 27 2008, "troy d. straszheim" <troy-AT-resophonic.com> 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
it.

>>> 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
http://www.boostpro.com