[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost
Subject:    Re: [boost] [modularization] Extract xml_archive from serialization
From:       Stephen Kelly <hello () steveire ! com>
Date:       2014-09-17 11:29:07
Message-ID: lvbr9r$7bj$1 () ger ! gmane ! org
[Download RAW message or body]

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.



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[prev in list] [next in list] [prev in thread] [next in thread]