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 _______________________________________________ Boost-cmake mailing list Boost-cmake@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-cmake
