From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-08-15 07:56:54
The Win32 regression tests will be run several times a day, depending on
activity, until the 1.29.0 release is complete.
See http://boost.sourceforge.net/regression-logs/cs-win32-index.html and
particularly
http://boost.sourceforge.net/regression-logs/cs-win32-diff.html
In the twelve hours or so since the last run, the great bulk of the
Boost.Test warnings have been fixed, and a number of other problems were
cleared too. I didn't have to manually kill any tests.
But there is one worrisome issue: looking at the bjam output log, it
appears that there were many Boost.Test compile failures. See example
below.
How could the many tests that depend on Boost.Test pass if the Boost.Test
library isn't being built? Is it possible that bjam is failing to
recognize this, and using the residue library from the previous run?
--Beman
metrowerks-C++-action
..\libs\test\build\bin\libtest_exec_monitor.lib\metrowerks\debug\runtime-link-dynamic\test_tools.obj
### mwcc Compiler:
# In: ..\boost\test\detail\unit_test_config.hpp
# From: ..\libs\test\src\test_tools.cpp
# ----------------------------------------
# 34: using std::distance;
# Error: ^^^^^^^^
# undefined identifier 'std::distance'
# (included from:
# unit_test_log.hpp:13
# test_tools.hpp:13
# test_tools.cpp:10)
Errors caused tool to abort.
mwcc -maxerrors 5 -maxwarnings 20 -c -warn on,nounusedexpr,nounused
-cwd include -DNOMINMAX -nowraplines -lang c++ -g -O0 -inline off -prefix
UseDLLPrefix.h -I"..\libs\test\build" -I- -I"C:\boost\site" -o
"..\libs\test\build\bin\libtest_exec_monitor.lib\metrowerks\debug\runtime-link-dynamic\test_tools.obj"
"..\libs\test\build\../src\test_tools.cpp"
...failed metrowerks-C++-action
..\libs\test\build\bin\libtest_exec_monitor.lib\metrowerks\debug\runtime-link-dynamic\test_tools.obj...
...removing
..\libs\test\build\bin\libtest_exec_monitor.lib\metrowerks\debug\runtime-link-dynamic\test_tools.obj