Re: [boost] [modularization] spirtit -> serialization

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
>>>>> optional
>>>>> dependencies.
>>>>
>>>> Why?
>>>
>>> Because it creates lots of tiny submodules, which creates maintainability
>>> and usability problems.
>>
>> Why?
>
> 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
> extracted.

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'
libs/geometry/sublibs
libs/spirit/sublibs
libs/algorithm/sublibs
libs/functional/sublibs
libs/utility/sublibs
libs/numeric/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
>>>> 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.

+1

That could work, but some concrete solution is needed.  However, if you
reconsider how much that differ from the solution above, maybe that is 
good enough?

--
Bjørn