Re: [boost] Re: trouble with generating html compiler status pages

[Beman Dawes]

At 10:14 AM 9/3/2003, Matthew Towler wrote:

>Beman Dawes wrote:
> >
> > Are you using run_tests.sh from CVS or your own script?
> >
>
>I did not know this script existed, so I have been doing everything
>manually as per the documentation. on
>http://www.boost.org/more/regression.html
>and making the obvious syntactic adjustments for unix
Ouch! My fault. I've added a link (in CVS) to run_tests.sh to reduce 
likelihood of it being missed.

>One thing I noticed is that this documentation indicates setting a
>BOOST_ROOT environment variable, whilst run_tests.sh uses boost_root, I
>was under the impression that case mattered - or is this irrelevant as
>boost_root is always passed into the executables on the command line
>rather than automatically referred to?
I don't know the answer to that. Someone familiar with running under Unix 
needs to answer.

>I retried the processing of the regression test results using the
>run_tests.sh script and got exactly the same result from
>'compiler_status', namely
>
>*** Error: std::runtime_error: boost::filesystem::directory_iterator
>constructor:
>"/scratch8/buildman/builds/linux_boost_1_30_2/0_2/tools/regression/build/bin
>":
>No such file or directory
>
>BOOST_ROOT (and boost_root in the script) were set to
>/scratch8/buildman/builds/linux_boost_1_30_2
>
>so I believe it is the processing program that is adding the spurious
>'0_2' to the path.
I would do several things if that happened here:

(1) run only on a single test (I usually use config_info). That makes 
testing simpler and quicker.
(2) inspect the bjam log file to see if anything obvious jumps out.
(3) look at the target directory to see that the expected files are 
present. I set -sALL_LOCATE_TARGET=D:\boost-regr, so GCC target ends up 
being:

D:\boost-regr\status\bin\config_info.test\gcc\debug\runtime-link-dynamic

A listing of that directory shows:

08/14/2003  09:08 AM         1,775,667 config_info.exe
08/14/2003  09:08 AM           196,220 config_info.obj
08/14/2003  09:32 AM             4,310 config_info.output
08/14/2003  09:32 AM             4,310 config_info.run
08/14/2003  09:32 AM                51 config_info.test
08/14/2003  09:43 AM             4,771 test_log.xml
The contents of test_log.xml are:

<test-log library="config" test-name="config_info" test-type="run" 
test-program="libs/config/test/config_info.cpp" 
target-directory="status/bin/config_info.test/gcc/debug/runtime-link-dynamic" 
toolset="gcc" show-run-output="true">
<compile result="succeed" timestamp="2003-08-14 13:43:35 UTC"></compile>
<link result="succeed" timestamp="2003-08-14 13:43:35 UTC"></link>
<run result="succeed" timestamp="2003-08-14 13:43:40 UTC">
GNU C++ version 3.3.1
... macro values ...
</run>
</test-log>

Where "macro values" is a long list. Is the test_long.xml file present? Are 
the various paths correct in it?

If test_log.xml is missing or wrong, the problem is in process_jam_log or 
bjam. If test_log.xml looks good, the problem is in compiler_status.

(4) Run compiler_status under a debugger, and trap the call stack at the 
point the exception is thrown. By inspecting the call stack, it should be 
possible to figure out where the bad path came from. Let me know; we might 
be able to add an error check or workaround.

>I also tried the script on IRIX (with the mipspro 7.3.1.3 compiler),
>with a script adjusted to set test_tools and toolset to mipspro.  I got
>the following (good) output for the processing
>
>processing the regression test results for mipspro:
>Usage: bjam [bjam-args] | process_jam_log [locate-root]
>  locate-root is the same as the bjam ALL_LOCATE_TARGET
>  parameter, if any. Default is boost-root.
>boost_root: /local/buildman/builds/boost-1.30.2
>locate_root: /local/buildman/builds/boost-1.30.2
>no errors detected
>generating html tables:
>Using /local/buildman/builds/boost-1.30.2/status/bin/config_test.test to
>determine compilers
>no errors detected
>done!
>
>However when I look at the generated webpage (cs-IRIX64.html), most of
>the tests are marked as missing. e.g. for regex regex_grep_example_1, 2,
>3, are marked as Missing, whilst regex_grep_example_4 is a Pass.
>
>Looking at the corresponding regress.log file, all of these four tests
>passed - and when located in $BOOST_ROOT running
>find . -name "*.xml" | grep example_
>gives
>./libs/regex/example/bin/regex_grep_example_1.test/mipspro/debug/threading-m
>ulti/test_log.xml
>./libs/regex/example/bin/regex_grep_example_2.test/mipspro/debug/threading-m
>ulti/test_log.xml
>./libs/regex/example/bin/regex_grep_example_3.test/mipspro/debug/threading-m
>ulti/test_log.xml
>./libs/regex/example/bin/regex_grep_example_4.test/mipspro/debug/threading-m
>ulti/test_log.xml
>./libs/regex/example/bin/regex_split_example_1.test/mipspro/debug/threading-
>multi/test_log.xml
>./libs/regex/example/bin/regex_split_example_2.test/mipspro/debug/threading-
>multi/test_log.xml
>
>so it would appear the output is there - so I do not understand why the
>tests are Missing.
That sounds like compiler_status is being invoked from the wrong working 
directory or in some other way is not finding the target directories. 
Again, isolate a single test on a single compiler, and follow it through.

HTH,

--Beman

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost