I've been making adjustments to the serialization library to permit it to be used as a DLL and I have a couple of questions. As an example, I looked at the Jamfile for testing the filesystem. It contains: test-suite "filesystem" : [ run libs/filesystem/test/path_test.cpp <lib>../../../libs/filesystem/build/boost_filesystem : : : <define>BOOST_ALL_NO_LIB=1 ] ... a) I presume the BOOST_ALL_NO_LIB is to suppress autolinking name generation of the libraries. Is this correct? b) the requirements included <lib> ... but not <dll>. Does this test Jamfile EVER test the dll version of the filesystem library? Now suppose the test is built with runtime-link/dll . I believe that would indicate that the msvc dll version of the C++ libraries will be used and the compiler will compile code accordingly. On the other hand the <lib> above suggests that this test should be built with static linking. This raises a couple of questions: a) b) would it not make more sense for the filesystem test use the dll version of the library when the dll version of the c++ library is being used? By the same token I would expect that if the static version of the c++ library is being used, then the static version of the filesystem library would be used. Of course this isn't a requirement, but just a presumption that the most likely scenario is that a user that wants to use C++ libraries in dll from would likely want the same for other libraries. c) ideally, if we had nothing but time I would like to be able to test all combinations debug/release <runtime-link>static/dynamic, <filesystem library>static/dynamic. What would be the most convenient way to do this. Robert Ramey