On Fri, May 30, 2014 at 5:02 PM, Peter Dimov
This only gives the primary dependencies; it would be nice for the
finished product to include the secondary module dependencies as well (without going into specifics what included what, just what module brought up the secondary dependency).
And here's the secondary report on smart_ptr. (My initial version listed modules in alphabetical order, not in discovery order, which was even more stunning as I hadn't the faintest idea why all these modules were deemed a dependency.)
Secondary dependencies for smart_ptr:
<snip>
range: adds algorithm adds functional adds regex
</snip> I'm not sure this report is giving an accurate representation of the true dependencies of smart_ptr. Boost.Range only depends upon Boost.Algorithm in the unit tests and within the collection_traits which I can't imagine you would use for a smart_ptr. Similarly if you are not using the regex functionality, smart_ptr will not be dependent on it. The collection_traits and regex includes are very easily avoided and I believe smart_ptr does not really depend on these at all. The dependency on Boost.Functional only occurs if you explicitly include boost/range/iterator_range_hash.hpp I think that the conditional dependencies by including subsets of headers is quite frequently used and therefore analysis needs to take this into account. It could very well be argued that the RegEx adaptor would be better implemented in the RegEx library. It could also be argued that the Range-based algorithms might be better placed in Boost.Algorithm. My rationale for them being in Boost.Range is merely that I have write access and permission to develop Boost.Range. The coordination effort between libraries would have been prohibitive initially. If I am mistaken about your dependencies then please let me know as I certainly deem it unacceptable that you should not be able to avoid dependencies on Boost.Regex in particular. I do however agree with one of your earlier comments to the effect that modularisation would not improve external quality factors for users but would require a large development cost. I'm sure we can achieve a lot more useful things with the same development effort. Regards, Neil Groves