Hi, Thanks for the response. It's unfortunate the you provide so much stop-energy. Robert Ramey wrote:
I think the notion of "dependency" is richer than can be captured in this sort of graph.
No one claimed the graph was some kind of universal all-encapsulating representation of "dependency *inverted commas*!".
So it can't be understood in terms of this graph alone.
The graph is showing public module dependencies. I think that's understood.
Consider another simple case - date time/serialization.hpp
most date/time users don't use this - but a few do. Is serialization a prerequisite for date/time? which users are we talking about? One can't win here. If you distribute serialization with every use of date/time you're distributing too much. If you don't, you'll be failing to ship functionality which some users need. What is the solution here - make two libraries out of date/time? or what?
The solution is to make serialization low-cost to depend on, so that depending on it is not a problem. That is exactly what I am recommending. The current problem with serialization is that it is expensive in terms of needless dependencies. My recommendation does a lot to solve that for serialization.
So the graph tells us something, but what?
Module/package dependencies.
So - the degree of "modularization" cannot be determined or illustrated or measured by examining the graph above.
Disputed.
So, taken to it's logical conclusion, extracting xml_archive would lead to extracting other components as well.
Nope. No one has suggested that. Extracting xml_archive isolates the spirit dependency. There is no similar motivation to extract other parts. I looked a little bit into splitting all of the archive parts away from the serialization part, but that still ties all the rest of the archive parts needlessly to spirit. What I recommend isolates the cost of spirit to the code that uses it. There could be reason to try to split the rest of the archive stuff from serialization, but I didn't look into that, so I'm not recommending it.
Traditionally, (and not just in boost) libraries have been organized around developer responsibility.
What I recommend doesn't change anything of this.
But the real questions are: a) what do we want modularization to accomplish and is this a feasible goal.
This is where you are providing a lot of bad stop-energy. Were not these questions answered years ago? Tell me this: Why did boost migrate away from svn to 100 fractured (not modularized!) git repos?
c) Do we want to support deployment of boost subset? I think we do.
This question was answered years ago. Why did boost migrate away from svn to 100 fractured (not modularized!) git repos?
My basic point is that these questions have to be addressed before the notion of decoupling can be carried much further.
Insisting that they are not already answered is not helpful.
In concrete terms - the exclusion of xml_archive should be: a) dropped altogether - (find by me btw)
FYI, "fine by me" is what you say when you agree with a proposal. Here you state the opposite of the proposal and say it's "fine by me" with a typo. It is a very strange way to express yourself.
b) created as a separate library module
This is the proposal. Thanks, Steve.