Robert Ramey wrote:

Stefan Slapeta

...

...is marked as expected failure for all toolsets! Is this really intended? (What does us tell a test that is expected to fail everywhere?)

This is marked with the ref note - "fails intermittently" - the failure is an result of the fact I haven't been able to make Jamfile run tests in a particular sequene.

I have a solution for you... First, you need to "fix" your Jamfile to return the test targets: =================================================================== RCS file: /cvsroot/boost/boost/libs/serialization/test/Jamfile,v retrieving revision 1.10 diff -u -r1.10 Jamfile --- Jamfile 14 Sep 2004 04:40:50 -0000 1.10 +++ Jamfile 3 Oct 2004 06:07:22 -0000 @@ -39,8 +39,9 @@ rule run-invoke ( test-name : sources * : defn * ) { Echo $(test-name) ; + local tests = ; # debug - return [ + tests += [ run $(sources) <lib>../../test/build/boost_test_exec_monitor @@ -67,7 +68,7 @@ # test. This permits them to appear in the same table built by # compiler_status if $(BOOST_SERIALIZATION_TEST_RELEASE) { - return [ + tests += [ run $(sources) <lib>../../test/build/boost_test_exec_monitor @@ -90,6 +91,7 @@ release ] ; } + return $(tests) ; } rule test-bsl-run ( test-name : sources * ) @@ -127,17 +129,24 @@ } rule test-bsl-run_polymorphic_archive ( test-name : sources * ) { + local tests = ; for local defn in $(BOOST_ARCHIVE_LIST) { - test-bsl-run_archive $(test-name) : polymorphic_$(defn:LB) - : - $(sources) ; + tests += [ + test-bsl-run_archive $(test-name) + : polymorphic_$(defn:LB) + : $(sources) ] ; } + return $(tests) ; } rule test-bsl-run_files ( test-name ) { + local tests = ; for local defn in $(BOOST_ARCHIVE_LIST) { - test-bsl-run_archive $(test-name) : $(defn:LB) ; + tests += [ + test-bsl-run_archive $(test-name) + : $(defn:LB) ] ; } + return $(tests) ; } test-suite "serialization" : =================================================================== Having that working, lets you define the tests so that they depend on each other (indirectly). For example: =================================================================== local test-suite-serialization-part-1 = [ test-bsl-run_files test_array ] [ test-bsl-run_files test_binary ] ; local test-suite-serialization-part-2 = [ test-bsl-run_files test_contained_class ] [ test-bsl-run_files test_cyclic_ptrs ] ; test-suite serialization : $(test-suite-serialization-part-1) $(test-suite-serialization-part-2) ; DEPENDS $(gLOCATE($(test-suite-serialization-part-2):G=directory-grist) : $(test-suite-serialization-part-1) ; =================================================================== That last DEPENDS makes the directory for the part 2 depend on the completion of part 1. You may ask why the directory and not the test itself? Strangely it's because to properly chain the tests you need to make the earliest step of the second test depend on the latest part of the next test. And directories are the only sure thing that you can know a test needs first. WARNING: That means that if, in the example above, any of the tests in part 1 fail, _none_ of the tests in part 2 will even attempt to build. Instead you'll get the "skipping target" messages. HTH. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq