The current situation with date-time is the following: user creates application which doesn't use serialization. Hence he doesn't include boost/data-time/serialization.hpp. His program compiles, links and runs. Clearly his program depends on boost/date-tiem but doesn't depend on boost serialization. I don't think this is a disputable fact. The module dependency tool may say that anything which depends upon date-time library is dependent upon serialization - but that is not true. I don't think this is disputable. So in my view the module decency tool should take one or more program sources as arguments and generate a list of modules which need to be included in order to compile/link and run the all the programs. This would tell a user exactly what he needs to know. When I test the date-time library I would include all the test programs as arguments and get one list of modules. Someone else might be only interested in one application and get a shorter list of modules. This would be useful to everyone. There will and can never exist at tool which gives you the exact list of required modules with specifying the applications to be built. So we're going to settle for some approximation. That's OK. it's better than nothing - but don't think that it's anything other than this. The current approximation is that of tracking the header inclusions. This includes more than a given application is likely to use so it's sort of overkill - this shows up as union of all possible modules which some application might need to build. It's not incorrect, just recognize that it's a blunt instrument. I can hear the cry - so what can we do so one doesn't have to download the whole of boost? Here's a suggestion which may satisfy those. Modest Proposal - Bridge module We create a new module - named "bridge". In this module there is a directory: boost/bridge/archive.hpp. This contains only forward declarations: class basic_iarchive; class basic_oarchive; and maybe some other miscellaneous stuff. This includes no headers from boost/archive. in date-time/serialization.hpp files in other libraries replace #include <boost/archive/basic_iarchive.hpp> with #include <boost/bridge/archive.hpp> Same is done in other libraries which implement serialization; Everything works the same as before. BUT the dependency tools now stop looking when they get to the bridge header. So our dependency display stops at date-time. I think this is an accurate reflection of what is desired. The building of applications which use date-time is exactly the same as it was before. The requirement to include (or not include) the boost serialization libraries is the same - that is it depends on which part of date-time the application actually uses. But there is a small difference - the application isn't including anything from boost/archive so the serialization library doesn't show up as dependent in the tools. Only the headers from boost/serialization are included. They are all header only and generally not dependent upon a lot of other boost stuff. This might be satisfactory. It does leave us with two different definitions of "module" though. since both boost/serialization and boost/archive are currently in the same "module". In fact most of the tests actually test things in serialization against all the "archives". So teasing this out could be a pain. I'm not even going to think about this now. I'm guessing that other libraries have some similar issues. This was raised previously by John Maddock under the heading "bridge libraries" he posed the question about how to deal with and we didn't really have an answer ... then. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/type-traits-Rewrite-and-dependency-free-v... Sent from the Boost - Dev mailing list archive at Nabble.com.