Subject: Re: [boost] [modularization] spirtit -> serialization
From: BjÃ¸rn Roald (bjorn_at_[hidden])
Date: 2014-06-15 08:57:06
On 06/15/2014 02:30 PM, Andrey Semashev wrote:
> 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
>>> 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 is now clear to me that you are thinking about git submodules, not the
mechanism supported by tools/boostdep which simply look for a sublibs
file, and if it exsist, it will look in subdirectories for
*/include/boost and if found treat it as a sub-module.
Boost.build already support this and it is in use in:
$ find libs -name 'sublibs'
>>>> 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
>>> You are right to desire not depending on Serialization if you don't use
>>> 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.
That could work, but some concrete solution is needed. However, if you
reconsider how much that differ from the solution above, maybe that is
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk