Re: [Boost-testing] [Important!] Testers.. New version of bjam, action likely required..

Subject: Re: [Boost-testing] [Important!] Testers.. New version of bjam, action likely required..
From: Belcourt, Kenneth (kbelco_at_[hidden])
Date: 2010-04-05 17:49:07

On Apr 5, 2010, at 3:16 PM, Rene Rivera wrote:

> On 4/5/2010 4:09 PM, Belcourt, Kenneth wrote:
>>
>> On Apr 5, 2010, at 2:31 PM, Belcourt, Kenneth wrote:
>>
>>>
>>> On Apr 5, 2010, at 2:29 PM, Belcourt, Kenneth wrote:
>>>
>>>>
>>>> On Apr 5, 2010, at 2:23 PM, Rene Rivera wrote:
>>>>
>>>>> I just put back the latest version of bjam, 3.1.18, used by the
>>>>> regression testing. Because subversion is not entirely intelligent
>>>>> when
>>>>> it comes to doing a checkout of a new branch over an existing tree
>>>>> you
>>>>> will likely need to delete the "tools_bjam" directory for things  
>>>>> to
>>>>> work.
>>
>> So I get the same error message about no boost-test lines encountered
>> (see below). Looking in results/bjam.log I see loads of lines like  
>> this
>> which clearly contain boost-test.
>>
>> boost-test(COMPILE_FAIL) "config/no_void_returns_fail" :
>> "libs/config/test/no_void_returns_fail.cpp"
>> boost-test(RUN) "config/no_void_returns_pass" :
>> "libs/config/test/no_void_returns_pass.cpp"
>> boost-test(COMPILE_FAIL) "config/no_wchar_t_fail" :
>> "libs/config/test/no_wchar_t_fail.cpp"
>> boost-test(RUN) "config/no_wchar_t_pass" :
>> "libs/config/test/no_wchar_t_pass.cpp"
>> ...patience...
>> ...patience...
>> ...patience...
>>
>> and then the tests start running. So what I'm confused is which  
>> python
>> file is emitting this message? I can't find where this message is  
>> coming
>> from.
>>
>> *****Error - No "boost-test" lines encountered.
>>
>> Any idea who's generating this error?
>>
>> -- Noel
>
>> Exception: Command sequence
>> "['"/tmp/kbelco/boost/tools_regression/build/bin/gcc-4.2.4/release/ 
>> process_jam_log"
>> "/tmp/kbelco/boost/results" <"/tmp/kbelco/boost/results/bjam.log"']"
>> failed with return code 256
>
> It's not a Python script generating those, it's the  
> process_jam_log.cpp
> program. No idea why a change in the bjam version would cause it to
> complain though.

Okay, the problem seems to be that this compile action precedes the  
first occurrence of boost-test in the results/bjam.log file.

gcc.compile.c++ /tmp/kbelco/boost/results/boost/bin.v2/libs/math/build/ 
gcc-4.2.4/debug/long_double_check.o

     "/sierra/Sntools/extras/compilers/gcc-4.2.4/bin/g++"  -ftemplate- 
depth-128 -O0 -fno-inline -Wall -g -fPIC  -DBOOST_ALL_NO_LIB=1  -I".."  
-c -o "/tmp/kbelco/boost/results/boost/bin.v2/libs/math/build/ 
gcc-4.2.4/debug/long_double_check.o" "/tmp/kbelco/boost/boost/libs/ 
math/config/has_long_double_support.cpp"

...updated 8 targets...
Performing configuration checks

     - long_double_check builds : yes
boost-test(RUN) "accumulators/weighted_tail_variate_means" : "libs/ 
accumulators/test/weighted_tail_variate_means.cpp"
boost-test(RUN) "accumulators/weighted_tail_quantile" : "libs/ 
accumulators/test/weighted_tail_quantile.cpp"

Notice the first boost-test lines occur after the compile action  
happens.  For some reason, process_jam_log.cpp seems to assume that  
once it finds any build / link action, it immediately tests the  
test2info map to see if it's empty.  In this case, it's always empty  
since the compile action occurs before the first boost-test line.

If I edit bjam.log and remove the compile action lines,  
process_jam_log runs to completion without error.  Guess we need to  
ping the Math library maintainer and ask why / how they're doing this?

Is that enough information to get a patch in place?

-- Noel