Toon Knapen <toon.knapen@fft.be> writes:
David Abrahams wrote:
I agree with that; no question about it. I think a few more degrees of classification than you've outlined could be useful:
core vs. optional
I hate "optional" but can't think of a better term right now. This is the distinction between, e.g., type traits and serialization
It's hard to draw the line between 'core' and 'optional' IMO. I guess 'core'-libraries would be libraries that are heavily used by other boost-libraries whereas 'optional' libraries are leafs in the library-dependency graph.
Roughly speaking, yes. Although I would mark Boost.Python as optional even though Boost.Graph and Boost.MultiArray have subparts that depend on it for Python bindings.
Therefore I think it just is important to have a clearly documented library-dependency-graph.
Yeah, that would indeed be great. I'm not sure how to accomplish it, though. -- Dave Abrahams Boost Consulting www.boost-consulting.com