There are other cases where some useful components could be split off from within libraries. For instance, many libraries could make use of boost::math::constants in cases where it doesn't make as much sense to have all of the statistical functions come along as another dependency.
There are a number of libraries which use the "core" of boost.math but don't need the whole thing - one that causes cyclic dependencies because of this is lexical_cast which is both used by Boost.Math (including the constants code unfortunately), and also uses a few core Math lib functions. One way to avoid that would be to split off a "Math.Core" lib which contained only a few common headers (no tests or docs etc). Trouble is constants can't be part of the core as it would bring back those cyclic dependencies to lexical_cast. They could be their own module I guess, but I'd really like to avoid too many splits. With regard to glue headers - the conclusion I've come to is that we need to manually break (by which I mean ignore) some dependencies. Consider, if lib B has a glue header for interoperability with lib A, then there's not any need to automatically track dependencies to A. After all the whole point of the glue header is to use the two libraries together, so it's not like the user doesn't know that they need both modules. To consider another cyclic dependency: the Math and Multiprecision libs. In fact a human observer looking at the code would conclude the dependency graph goes in one direction - from Multiprecision to Math (again a small part of it). But there is one Math lib header which *may* under some circumstances (user sets a particular macro) include some multiprecision headers. Further that header only exists to assist in the generation of new numeric constants - whether by the user or by the Math lib's maintainers. So it's usage will be very infrequent, and since the user has to explicitly tell it to use Boost.Multiprecision it's not like they don't know that it's needed. I guess we could use macro's to obfuscate the #includes so there's no dependency tracking in these cases, but it seems a stupid thing to do (obfuscating the code, and possibly breaking build tool support) just to keep the modularization folks happy. So I think I'd like the folks pushing for modularization to provide a way for us to annotate headers with a "don't track here" direction. Thoughts? John.