Reece Dunn wrote:

I don't know how feasable this would be, but you might also want to consider library dependancies so that if you modify the iterator adaptors library you can pull a list of tests that need to be re-run because the associated libraries use iterator adaptors. This would reduce the number of tests that need to be performed on each cycle, but you'd need some way of archiving the results and only updating the ones that are re-run.

I thought that's what it already did! Isn't that the whole point of the BJAM system? Is there not a way to "compose" Jamfile(s) into a one so that only dependent tests are run? Just a thought. More food for thought. The serialization library relies on spirit. The current version of spirit (1.8?) doesn't build on older platforms such as VC 6. For me this isn't a problem. For testing on other platforms spirit 1.61 will have to be installed in a "known" place. These kind of testing tweaks can occur inside the runtest.sh but that would inhibit the composition of Jamfiles described above. - maybe this is not a consideration. I recognize that the current testing procedure is exhaustive and that's a good thing. If I were to add exhaustive testing of the serialization library (35 tests * 5 archives (maybe 10) * 2 (debug/release) * 2 (dll/lib) * 8 compilers ) that would be 5600 build and run tests. This would take a while. (I havn't included polymorphic archive versions which would double this). So I'm resigned to the fact that I'm not going to be able to test exhaustively on a continuing basis. I would like to be able to solicite a test for a given combination on demand. Robert Ramey