Robert Ramey wrote:

John Maddox brought up the question of "bridge libraries" (?) . An example would be the serialization library includes tests for boost variant but doesn't use boost variant itself. So if one includes just the modules which the serialization library uses to build - you'll get one set of modules which won't include the ability to run the test set. If you include all the modules which test set requires, you're going to include half of boost.

Yes, in general, there are three sets of dependencies: what the library headers depend on, what the library sources depend on, and what the library tests depend on, each a superset of the previous one. This doesn't make such a tool worthless or impossible though. And - FWIW - bridge libraries are something else, I think. The problem there is that, f.ex. a library X may not depend on the serialization library but making X's types serializable would. A bridge library XS could solve this by depending on both X and serialization and providing the necessary support. In principle, I've always argued that libraries should be designed in such a way so that adding support should not require including a header, but that's not the path of least resistance and if one doesn't specifically keep that requirement in mind, it's rare to see it satisfied. (And it's not always possible.) For example, here's how the smart pointers provide hash support without including anything: namespace boost { // hash_value template< class T > struct hash; template< class T > std::size_t hash_value( boost::intrusive_ptr<T> const & p ) { return boost::hash< T* >()( p.get() ); } } // namespace boost and this is how a type may be specified to be a (boost::bind) placeholder, again without any inclusions: namespace boost { template<class T> struct is_placeholder; template<int I> struct is_placeholder< my_placeholder<I> > { BOOST_STATIC_CONSTANT( int, value = I ); }; } // namespace boost