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

Subject: Re: [boost] [modularization] spirtit -> serialization
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-06-15 09:07:44

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.

> 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.

> 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.

> In
> addition, if you include the right header of module X you'd be fine, and if
> you include the wrong header, you'll bring in the world. In another
> addition, if the right header of X is changed to include a wrong header
> from X, you'll suddenly start depending on the world.

True. Although you're not saved from changes when you build dependency graph 
based on submodules. I'd say, you're more vulnerable to dependency creep in 
case of submodules than headers.

I guess, it all comes down to how we're going to use this dependency 
information. If our packaging/deploying tool is based on submodules then we 
should follow that line. In this case I would prefer that your above sub-sub-
module approach is taken as a baseline; breeding repositories is not the way 
to go, IMHO. If the tool is header based then the submodules are just a 
convention to separate libraries, grant privileges and that's about it.