Re: Re: [boost] [serialization] test_level_class_info_load*...

From: Robert Ramey (ramey_at_[hidden])
Date: 2004-10-06 01:20:38

>First, you need to "fix" your Jamfile to return the test targets:
>...

OK

>===================================================================

>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)
>;

Now - out of curiosity, most of the rule are of the form:

rule test-bsl-run_polymorphic_archive ( test-name : sources * )

which suggests to me that I could just use:

test-suite serialization :
    [ test-bsl-run_files test_level_class_info_load
test_level_class_info_save ]

Which would make ...load dependant on ...save.  Or this is this answered by
the following:

>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.

Robert Ramey