|
|
Boost Interest : |
From: David Abrahams (dave_at_[hidden])
Date: 2008-06-01 20:06:17
on Sat May 31 2008, "troy d. straszheim" <troy-rPoGFrA5WPqukZHgTAicrQ-AT-public.gmane.org> wrote:
>>>>> 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)
Yes :(
> is that ctest scrapes
> build log files,
I forgot about that :(
> 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.
Yes, that's what bjam is doing today. It uses popen to invoke all the
commands and capture their output. To do the same with CMake you may
need to request/implement some patches (?)
>> 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.
Okeydoke
-- Dave Abrahams BoostPro Computing http://www.boostpro.com