I tried the following:
./bootstrap.sh --exec-prefix=/usr/local
./bjam --layout=versioned --build-type=complete
cd status
../bjam
And I was planning the following if the result of the above was acceptable.
./bjam install
However, every time I have tried this, it stops part way through, at the following the last few lines:
../boost/iterator/iterator_facade.hpp:514: warning: type qualifiers ignored on function return type
gcc.compile.c++ ../bin.v2/libs/regex/test/regex_regress_threaded.test/gcc-4.3.4/debug/threading-multi/regress/test_unicode.o
In file included from ../boost/date_time/posix_time/posix_time_system.hpp:14,
from ../boost/date_time/posix_time/ptime.hpp:12,
from ../boost/date_time/posix_time/posix_time_types.hpp:12,
from ../boost/thread/thread_time.hpp:11,
from ../boost/thread/locks.hpp:12,
from ../boost/thread/pthread/mutex.hpp:12,
from ../boost/thread/mutex.hpp:16,
from ../boost/thread/pthread/thread_data.hpp:12,
from ../boost/thread/thread.hpp:17,
from ../boost/thread.hpp:13,
from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\/info.hpp:27,
from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\/test_not_regex.hpp:22,
from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\/test.hpp:31,
from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\test_unicode.cpp:21:
../boost/date_time/time_system_split.hpp:41:1: warning: use of C99 long long integer constant
gcc.compile.c++ ../bin.v2/libs/regex/test/regex_regress_threaded.test/gcc-4.3.4/debug/threading-multi/regress/test_overloads.o
In file included from ../boost/date_time/posix_time/posix_time_system.hpp:14,
from ../boost/date_time/posix_time/ptime.hpp:12,
from ../boost/date_time/posix_time/posix_time_types.hpp:12,
from ../boost/thread/thread_time.hpp:11,
from ../boost/thread/locks.hpp:12,
from ../boost/thread/pthread/mutex.hpp:12,
from ../boost/thread/mutex.hpp:16,
from ../boost/thread/pthread/thread_data.hpp:12,
from ../boost/thread/thread.hpp:17,
from ../boost/thread.hpp:13,
from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\/info.hpp:27,
from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\/test_not_regex.hpp:22,
from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\/test.hpp:31,
from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\test_overloads.cpp:12:
../boost/date_time/time_system_split.hpp:41:1: warning: use of C99 long long integer constant
gcc.compile.c++ ../bin.v2/libs/regex/test/regex_regress_threaded.test/gcc-4.3.4/debug/threading-multi/regress/test_operators.o
In file included from ../boost/date_time/posix_time/posix_time_system.hpp:14,
from ../boost/date_time/posix_time/ptime.hpp:12,
from ../boost/date_time/posix_time/posix_time_types.hpp:12,
from ../boost/thread/thread_time.hpp:11,
from ../boost/thread/locks.hpp:12,
from ../boost/thread/pthread/mutex.hpp:12,
from ../boost/thread/mutex.hpp:16,
from ../boost/thread/pthread/thread_data.hpp:12,
from ../boost/thread/thread.hpp:17,
from ../boost/thread.hpp:13,
from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\/info.hpp:27,
from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\/test_not_regex.hpp:22,
from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\/test.hpp:31,
from C:\cygwin\home\Ted\boost_1_45_0\libs\regex\test\regress\test_operators.cpp:12:
../boost/date_time/time_system_split.hpp:41:1: warning: use of C99 long long integer constant
gcc.link ../bin.v2/libs/regex/test/regex_regress_threaded.test/gcc-4.3.4/debug/threading-multi/regex_regress_threaded.exe
The last gcc.link statement above has been the last statement in the cygwin bash console for about 12 hours now. I am rather surprised that either bjam or a test program it is running can stop like that and not have bjam detect it and respond appropriately. Is there a way to prevent this from happening?
I know (from having tried it), that I can terminate this and re-execute bjam in status, and that that will finish, but doing that doesn't tell me what fraction of tests succeeded. Rather, it tells me only about those targets that were found, and their result, during the current executin. Obviously, it will ignore all the tests that had been performed previously.
I also see a lot of files created in status during the test. Is there a script that will process the contents of status and tell me at least the sort of info provided in the table on " http://www.boost.org/development/tests/trunk/developer/summary.html"?
Thanks
Ted