Re: [Boost-testing] Trunk testing broken.

Subject: Re: [Boost-testing] Trunk testing broken.
From: Belcourt, Kenneth (kbelco_at_[hidden])
Date: 2010-04-05 13:55:17

On Apr 4, 2010, at 10:15 AM, Vladimir Prus wrote:

> Rene Rivera wrote:
>
>> K. Noel Belcourt wrote:
>>>
>>> On Mar 24, 2010, at 1:18 PM, Rene Rivera wrote:
>>>
>>>> K. Noel Belcourt wrote:
>>>>>
>>>>> On Mar 23, 2010, at 3:59 PM, Rene Rivera wrote:
>>>>>
>>>>>> Vladimir Prus wrote:
>>>>>>> Rene Rivera wrote:
>>>>>>>
>>>>>>>> Belcourt, Kenneth wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> The log files for various trunk toolsets show this error.  Can
>>>>>>>>> someone
>>>>>>>>> please take a look?
>>>>>>>> The only immediate guess is the new bjam version. So I reverted
>>>>>>>> testing
>>>>>>>> back to 3.1.17 until I can figure out the problem.
>>>>>>>
>>>>>>>>> # Starting tests ("/scratch/boost/tools_bjam/bin.linuxx86_64/ 
>>>>>>>>> bjam"
>>>>>>>>> "-sBOOST_BUILD_PATH=/scratch/boost:/scratch/boost/tools_bb"
>>>>>>>>> "-sBOOST_ROOT=/scratch/boost/boost" "--boost=/scratch/boost/ 
>>>>>>>>> boost"
>>>>>>>>> "--boost-build=/scratch/boost/tools_bb" "--debug- 
>>>>>>>>> configuration"
>>>>>>>>> -l300
>>>>>>>>> intel-11.1 -d2 preserve-test-targets=off --dump-tests -j8
>>>>>>>>> "--build-dir=/scratch/boost/results"
>>>>>>>>>>> "/scratch/boost/results/bjam.log"
>>>>>>>>> 2>&1)...
>>>>>>>>> # Running Boost.Build tests
>>>>>>>>> # Using bjam binary in '/scratch/boost/tools_bjam/ 
>>>>>>>>> bin.linuxx86_64'
>>>>>>>>> # Getting test case results out of
>>>>>>>>> "/scratch/boost/results/bjam.log"...
>>>>>>>>> boost_root: /scratch/boost/boost
>>>>>>>>> locate_root: /scratch/boost/results
>>>>>>>>> *****Error - No "boost-test" lines encountered.
>>>>>>>>>     (Usually occurs when bjam was envoked without the --dump- 
>>>>>>>>> tests
>>>>>>>>> option
>>>>>>>>>      or bjam was envoked in the wrong directory)
>>>>>>>
>>>>>>> FWIW, running trunk version of bjam from status dir does  
>>>>>>> produce the
>>>>>>> 'boost-test(XXX)'
>>>>>>> output.
>>>>>>
>>>>>> So perhaps it is what Richard mentioned about subversion being  
>>>>>> stupid.
>>>>>> And we all need to remove the bjam dir.
>>>>>
>>>>> Hi,
>>>>>
>>>>> Here's how I run the tests, my nightly scripts are setup to  
>>>>> toast all
>>>>> directories before running the tests.
>>>>>
>>>>> rm -rf tools_bb tools_bjam tools_regression tools_regression_src
>>>>> rm -rf results
>>>>> rm -rf boost
>>>>>
>>>>> Next I setup some paths and copy in the necessary files and then  
>>>>> run the
>>>>> tests like this.
>>>>>
>>>>> python run.py --proxy="http://wwwproxy.sandia.gov:80"
>>>>> --runner="Sandia-gcc-4.2.4" --bjam-toolset=gcc --pjl-toolset=gcc
>>>>> --toolsets=gcc-4.2.4 --bjam-options="-j16 link=static" >&!
>>>>> gcc-4.2.4.boost.log
>>>>>
>>>>> So what bjam directory do I need to remove, sorry if I'm being  
>>>>> obtuse?
>>>>
>>>> It would be the tools_bjam dir you are already removing. So I'm  
>>>> at a
>>>> loss as to why the new bjam didn't work for you :-(
>>>
>>> I'm available today for a while if you have any suggestions or  
>>> want me
>>> to try some things to diagnose this.
>>>
>>> Please let me know.
>>
>> You could try running the unit tests for bjam in the machine that's
>> causing the problem. And of course manually running the tests, with  
>> bjam
>> -n --dump-tests, to see if it is/isn't doing the output with the new
>> version of bjam.
>
> did the above suggestion sched any light on the problem? Were issues  
> localized
> to some specific machines -- if so, which? Or it was a general messup?
> Does the problem reproduces when "run.py" is invoked from a terminal,
> as opposed to whatever cron is used to run them normally?

Alright, I checked out this tag:

        http://svn.boost.org/svn/boost/tags/tools/jam/Boost_Jam_3_1_18

and ran the tests, they all passed (see output below).  So I'm not  
sure what caused the problem reported earlier.

Can you update trunk again with 3.1.18 and I'll start running tests  
once you've done the commit?

-- Noel

[kbelco_at_wsblade001 test]$ pwd
/scratch/junk/Boost_Jam_3_1_18/test

[kbelco_at_wsblade001 test]$ ./test.sh
###
### Using 'gcc' toolset.
###
rm -rf bootstrap
mkdir bootstrap
gcc -o bootstrap/jam0 command.c compile.c debug.c expand.c glob.c  
hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c  
make1.c newstr.c option.c output.c parse.c pathunix.c pathvms.c  
regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c  
modules.c strings.c filesys.c builtins.c pwd.c class.c native.c md5.c  
w32_getreg.c modules/set.c modules/path.c modules/regex.c modules/ 
property-set.c modules/sequence.c modules/order.c execunix.c fileunix.c
./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root= clean
...found 1 target...
...updating 1 target...
[DELETE] clean
...updated 1 target...
./bootstrap/jam0 -f build.jam --toolset=gcc --toolset-root=
...found 48 targets...
...updating 1 target...
[COMPILE] bin.linuxx86_64/bjam
...updated 1 target...
../src/bin.linuxx86_64/bjam -f test.jam -sBJAM=../src/bin.linuxx86_64/ 
bjam
Testing: ../src/bin.linuxx86_64/bjam
--- Testing "actions status results"...
--- action_status: PASSED(2) *FAILED(0)*

--- Testing "actions quietly"...
--- actions_quietly: PASSED(2) *FAILED(0)*

--- Testing NORMALIZE_PATH builtin...
--- builtin_normalize_path: PASSED(52) *FAILED(0)*

--- Testing SHELL builtin...
--- builtin_shell: PASSED(8) *FAILED(0)*

--- Testing W32_GETREGNAMES builtin...
--- builtin_w32_getregnames: PASSED(0) *FAILED(0)*

--- Testing -d2 option...
--- option_d2: PASSED(1) *FAILED(0)*

--- Testing -l option...
--- option_l: PASSED(1) *FAILED(0)*

--- Testing -n option...
--- option_n: PASSED(1) *FAILED(0)*

--- Testing -jN parallel execution of actions...
--- parallel_actions: PASSED(1) *FAILED(0)*

--- Testing -jN parallel execution of multi-file actions - 1...
--- parallel_multifile_actions_1: PASSED(1) *FAILED(0)*

--- Testing -jN parallel execution of multi-file actions - 2...
--- parallel_multifile_actions_2: PASSED(1) *FAILED(0)*

-- Testing parameter passing...
--- rule_param: PASSED(38) *FAILED(0)*

--- Testing var expansion...
--- stress_var_expand: PASSED(4) *FAILED(0)*

--- Testing var on target semantics...
--- target_var: PASSED(4) *FAILED(0)*

--- Testing var expansion...
--- var_expand: PASSED(9) *FAILED(0)*

--- Complete: *FAILED(0)*