Re: [Boost-cmake] dart as trac plugin

From: troy d. straszheim (troy_at_[hidden])
Date: 2008-05-31 11:37:00

David Abrahams wrote:
> 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.

Sounds reasonable to me.  You've got svn-python bindings, shouldn't be
terribly difficult to build/maintain.

> 
>>>> 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.

It looks like this is all doable, but one of the nasty problems (as you pointed
out in one of your 'release tools analysis' posts, iirc) is that ctest scrapes
build log files, and these logfiles vary in format from platform to platform.

See this thread:

   http://www.cmake.org/pipermail/cmake/2008-May/022034.html

The problem I have with this is that the underlying architectural
problem persists...   scraping these logfiles is always going to be a PITA,
Generally we'd like to catch the output of builds/tests at a much
lower level so that we can control what the slaves report and how often
they do so.  I'll send a little discussion/RFC on this under separate cover today.
I'll also try to put up the current incarnation of 'traash' (trac/dart).

>>>> 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?

Let's me get this ctest-rfc out and the traash demo up, let's discuss that,
then decide.

-t