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

List:       boost
Subject:    Re: [boost] [modularization] Extract xml_archive from serialization
From:       Vladimir Prus <ghost () cs ! msu ! su>
Date:       2014-09-17 12:33:01
Message-ID: lvbv1t$n7m$1 () ger ! gmane ! org
[Download RAW message or body]

On 09/17/2014 03:23 PM, Stephen Kelly 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 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.

Stephen,

speaking purely as a person who used serialization in the past,
I'm not sure I understand what you propose *exactly*. I thought that unless you
include XML archive headers, serialization does not actually pull in Spirit headers.

So what's your proposal exactly, since "extracting an xml_archive library from \
serialization" is not entirely clear to me.

> > b) created as a separate library module

If that's your proposal, I would be -1 on this, if anybody bothered to care about my \
opinion. In particular, that would mean that any changes to serialization library \
that affect XML archives and other parts would happen in two different repositories, \
with no obvious way to relate per-repository changes.

MPL maintainers too a different approach to this, by creating two submodules inside a
single repository - which seems a bit better to me.

- Volodya



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


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