I dare say that Boost.Test should avoid dependencies on boost libraries. I would suggest isolating the MPL dependencies even if that means re-implementing the parts that it uses. Boost.Test is special and avoiding cyclic dependency will help us not go insane.
Joel de Guzman
At the moment Boost.Test directly depends on: boost/call_traits.hpp boost/config.hpp boost/config/auto_link.hpp boost/cstdlib.hpp boost/current_function.hpp boost/detail/workaround.hpp boost/function/function0.hpp boost/function/function1.hpp boost/limits.hpp boost/mem_fn.hpp boost/mpl/for_each.hpp boost/mpl/identity.hpp boost/preprocessor/arithmetic/add.hpp boost/preprocessor/repetition/repeat.hpp boost/preprocessor/seq/for_each.hpp boost/progress.hpp boost/scoped_ptr.hpp boost/shared_ptr.hpp boost/type.hpp boost/type_traits/add_const.hpp boost/type_traits/add_pointer.hpp boost/utility.hpp boost/utility/addressof.hpp boost/utility/base_from_member.hpp boost/version.hpp Actually MPL and Boost.Function dependency is not critical yet since it does not affect library compilation and used only for extensions. But I definitely is not going to reimplement all above headers. Don't forget that Boost.Test among other things is standalone library and in may have need for use some existent core components. I wanted to propose to introduce macro BOOST_INTERNAL_TEST. If this macro is defined I will try to ifdef out optional dependencies. Boost libraries authors may define this symbol. Though In general I do not see anything wrong with Boost.Test dependencies on other boost components unless it introduce loops: Boost.Test depends on component that uses Boost.Test for unit testing. I believe it resolvable by using different layers of Boost.Test or with macro proposition above. In a near future I plan to use boost::optional, iterator_facade boost::lexical_cast and probably boost::function and boost::bind. And I am sure dependency keep grow. My only limitation is that it should work on all platforms where we perform regression testing. Regards, Gennadiy.