|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2007-08-09 13:20:13
on Wed Aug 08 2007, "John Maddock" <john-AT-johnmaddock.co.uk> wrote:
> Just thinking out loud here, but I've always thought that our test results
> should be collected in a database: something like each test gets an XML
> result file describing the test result, which then gets logged in the
> database. The display application would query the database, maybe in
> real-time for specific queries and present the results etc.
Sure, that's what the Trac plugin would do.
> Thinking somewhat outside the box here ... but could SVN be
> conscripted for this purpose,
The biggest downside of that idea is that it would be very expensive
in SVN resources to ever give real-time feedback from testing, because
you'd need a separate checkin for each build step.
> yes, OK I know it's an abuse of SVN, but basically our needs are
> quite simple:
>
> * Log the output from each build step and store it somewhere, with
> incremental builds much of this information would rairly change. In fact
> even if the test is rebuilt/rerun the chances are that logged data won't
> actually change.
> * Log the status of each test: pass or fail.
> * Log the date and time of the last test.
>
> So what would happen if build logs for each test were stored in an
> SVN tree set aside for the purpose, with pass/fail and date/time
> status stored as SVN properties? Could this be automated, from
> within bjam or CMake or whatever?
Sure it could.
So you *are* actually advocating a separate file in SVN for each test?
I guess I also worry about the performance cost of doing a checkin for
each test.
> Of course we're in serious danger of getting into the tool writing
> business again here ....
Unless we entirely drop our display distinctions and markup, or we
stick with the same fragile/unreliable display tools we have,
*someone* has to write new display tools. There just aren't any
existing tools out there that do what we want.
Unless Kitware is prepared to accomodate our display requirements, I
don't know where those tools are going to come from other than from
within Boost.
-- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk