Boost Testing :
From: David Abrahams (dave_at_[hidden])
Date: 2007-03-27 13:40:31
on Sat Mar 24 2007, Martin Wille <mw8329-AT-yahoo.com.au> wrote:
>>> On Windows I go to the library's test directory and just run the
>>> attached batch files; I'd expect these tools to work in the same way
>>> on other platforms too.
>>> If the tester and the developer manage to agree to work on a problem
>>> for an hour or two, they could test corrections almost in real time,
>>> with a dramatically reduced turnaround time.
>> I've gotten the impression that Martin doesn't feel comfortable
>> dealing with bjam directly, but it would be great if I was wrong.
> It takes me some time to figure out what command I have to run for each
> particular request (this includes command line options, environment
> variables, how not to disturb other test data, to check whether any
> modifications from to previous requests have to be undone, etc)
<snip> more reasons why Martin finds bjam uncomfortable.
Martin, regardless of your discomfort, could we please follow my
amended version of Nicola's suggested procedure, detailed below? We
still obviously have some problems on your machines, as
shows. I don't see how we have the slightest hope of clearing these
problems on your machines unless I can see the actual commands used to
invoke, and the errors reported by, the run. Ideally, you could grant
me temporary access to the actual systems running the tests so I could
try to reproduce the problems there. Failing that, I have an account
with nearly every major IM system and we could set up a chat session
to handle this.
[Misha, Beman, anybody? I don't know whether this is a
process_jam_log problem or a results postprocessing problem, but *I
have pleaded repeatedly* for someone to fix it: failing run tests
appear without showing much of the information we need on the web!]
on Sat Mar 24 2007, David Abrahams <dave-AT-boost-consulting.com> wrote:
> on Sat Mar 24 2007, Nicola Musatti <Nicola.Musatti-AT-gmail.com> wrote:
>> Pardon my butting in, but when hunting problems in a specific library,
>> wouldn't it be simpler and faster to just run the tests for that
>> library and use process_jam_log and compiler status to collect the
> It would be faster and simpler to just run the tests for that library
> and look at the jam log. process_jam_log leaves out important
> information when a "run" test fails, and doesn't add anything useful
> for the person trying to analyze a problem.
-- Dave Abrahams Boost Consulting www.boost-consulting.com