Re: [Boost-cmake] dart as trac plugin

From: troy d. straszheim (troy_at_[hidden])
Date: 2008-05-29 02:42:40

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.

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

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

-t