Appologies if you've seen this before. I've had problems with Google groups so I don't know if anyone saw this. I'm trying Nabble now. I remember that you originally brought up the question of "bridging" headers and I thought about that. Take for example the serialization library. The multi precision library implements the code required by the serialization library in order to save and restore multi precision data types to an archive. So it includes some headers from the serialization library. But is the multiprecision anyway dependent upon the serialization library? Well, most people will using multi precision without needing or wanting the serialization library. So should the current dependency scheme is going to be found wanting for those people. Before someone comes ups with the great idea - "just move all the multi precision serialization code in to the serialization library itself consider the question from the serialization library point of view. Now he is "dependent" on multi-precision library even though he doesn't use it. We've just shifted the problem from one place to another. So consider saying that multi precision serialization is a separate module. Aside from the proliferation of modules and confusion that this would entail there's still a problem. Running the tests for a library depends on still more modules. Since I would like to see more users run the test suite for the modules they use on their own environment then we've got some other dependencies. Basically - we just have to recognize that our "dependency minimization" efforts will never be definitive. But I think the exercise is useful, especially the breaking of cycles and eliminating gratuitous dependencies, as long as it doesn't become an end in itself. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/modularization-spirtit-serialization-tp46... Sent from the Boost - Dev mailing list archive at Nabble.com.