Subject: Re: [boost] [modularization] spirtit -> serialization
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-06-15 08:30:44
On Sunday 15 June 2014 13:49:20 Vicente J. Botet Escriba wrote:
> Le 15/06/14 13:40, Andrey Semashev a Ã©crit :
> > On Sunday 15 June 2014 13:26:52 Vicente J. Botet Escriba wrote:
> >> Le 15/06/14 12:48, Andrey Semashev a Ã©crit :
> >>> On Sunday 15 June 2014 12:13:08 Vicente J. Botet Escriba wrote:
> >>>> Le 14/06/14 18:34, Stephen Kelly a Ã©crit :
> >>>>> Vicente J. Botet Escriba wrote:
> >>>> Yes, and I propose to create a date_time.serialization submodule that
> >>>> breaks the date_time -> serialization dependency.
> >>>> date_time.serialization -> date_time serialization
> >>> The approach of extracting glue headers to separate submodules is not
> >>> scalable. We have many other libraries using the same approach to
> >>> optional
> >>> dependencies.
> >> Why?
> > Because it creates lots of tiny submodules, which creates maintainability
> > and usability problems.
What you mean why? Submodules are a constant pain to deal with. They don't
allow the complete history of the library, they don't allow synchronized
operations on them (e.g. do changes to multiple submodules in a single
commit/push), adding or removing them requires privileges. In Log I have at
least 6 glue headers, I don't want to deal with 7 different repos if they are
> >> I don't see why I would depend on Serialization if I don't use it
> >> even if I use DateTime. IMHO, it is up to the client of the
> >> serialization of the DateTime types to use the DateTime.Serialization
> >> sub-module.
> > You are right to desire not depending on Serialization if you don't use
> > it.
> > But this should not be achieved with submodules, IMHO.
> I'm open to discuss any alternative solving the issue.
I think there was a proposal not long ago to track dependencies based on
headers, pretty much like boostdep does. Then we only need to mark the
optional headers in some metadata files and there you go.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk