Andrey Semashev wrote:
On Tuesday 16 September 2014 09:42:25 Robert Ramey wrote:
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 will be to separate the dependency on Serialization into an optional component. This can be a header or a git submodule or a sublib in DateTime or something else. What exactly this is is defined by a number of aspects, including maintenance convenience, access control, distribution and deployment infrastructure. I agree that many of these aspects are not defined at the moment, but from the perspective of maintenance, access permissions and modularization effort a sublib looks most feasible to me.
Having tens of tiny 1/2/3 file 'sublibs' is not good.
c) serialization of other library components - e.g. shared_ptr - which depends on share_ptr itself.
These are probably the best candidates for separating from the core.
However, they do little to affect the dependency graph. I keep prioritizing things that affect the dependencies the most. Currently that's the serialization->spirit edge and the range->algorithm edge. Thanks, Steve.