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

Subject: Re: [boost] [modularization] spirtit -> serialization
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-06-15 09:43:20

Le 15/06/14 15:07, Andrey Semashev a écrit :
> On Sunday 15 June 2014 15:44:49 Peter Dimov wrote:
>> Andrey Semashev wrote:
>>> 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 understood Vicente to mean a sub-sub-module.
> When I read this:
>
>> Yes, and I propose to create a date_time.serialization submodule that
>> breaks the date_time -> serialization dependency.
> I got the idea that Vicente meant the full fledged git submodule, with its own
> repository. If we're talking about just structural changes within the same
> submodule then the perspective changes.

I requested on this list what was the criteria for associating a file to 
a module(sub-module) and Peter gave me the criteria. I'm just using it.

>
>> These don't have their own
>> repos. They are a subdirectory in an existing repo, and have the directory
>> structure of a module.
>>
>> date_time/
>>      include/
>>      src/
>>      test/
>>      serialization/
>>          include/
>>          src/
>>          test/
>>
>> boostdep will show this as date_time~serialization (like
>> numeric~conversion).
> Yes, this approach looks more interesting.
Sorry if I was not clear enough. I have already extracted Stopwatches 
from Chrono in this way.
>
>> Tracking headers instead of modules has its own disadvantages. The module
>> levels report, for example, would no longer make sense, as parts of the same
>> module would need to be at level 0 and other parts at level 11.
> Yes, although I don't really understand what a level means. It surely doesn't
> correspond to the number of dependencies, although there is some correlation.
> When deciding whether to use a library in my library I will be looking at its
> dependencies, not some level index.
See my comment on level on the other post.

Vicente