Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-09-22 10:37:33


Misha Bergal <mbergal_at_[hidden]> writes:

> David Abrahams <dave_at_[hidden]> writes:
>
>> I posted this yesterday, but got no reply. Can anyone explain the
>> vast number of white cells in the Boost.Python regression log? In
>> particular, the tests noted below don't look like they're reported
>> correctly in the log.
>
>
> White cells (missing test results) are caused by inability of
> process_jam_log (utility which produces xml result files from bjam
> log) to handle Boost.Python tests compile/link/execute failures.
>
> Having done some research I believe that the main problem is that the
> following bjam.log snippet:
>
> ...skipped <@boost!libs!python!test\args.test\msvc-stlport\debug\threading-multi>args.run
> for lack of <@boost!libs!python!test\args.test\msvc-stlport\debug\threading-multi>args.pyd...
>
> is treated by process_jam_log as:
>
> 1. Failed to build "args.run" in directory "args.test/..." because
> file args.pyd in the _same directory_ is missing.
>
> 2. If it is in the same directory, then it is something internal to
> args.test and it and failure to build it has already been processed
> and all relevant info has been dumped into xml results file in
> "args.test/..." directory. So process_jam_log just skips this
> message.
>
> The real situation is different (I am speculating here - our boost
> regression machine is in the middle of clean run, so I don't have all
> logs etc.)
>
> For one, args_ext.pyd was built in args_ext.pyd directory and xml
> result file with failure was written in args_ext.pyf/... directory.
>
> It is not clear to me what happens in Boost.Python build next.
>
> At this point I would appreciate if somebody clarified to me how
> Boost.Python build works, so I can figure out how to handle it in
> process_jam_log.

Sorry, I don't remember :(

I'll try to do an analysis later today. Thanks for looking at this.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk