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:36:31

Le 15/06/14 14:44, Peter Dimov a écrit :
> 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. 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 is exactly what I'm proposing.
>> 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.
>
Optional headers should be associated to a sub-module as this reduce the 
dependencies. This is not hard to do.

A different case is a file D.hpp that includes conditionally 
(preprocessor) another file B.hpp. IMO, this makes D depend on B until 
we don't include a context for the dependency relationship. This context 
could include a platform, a compiler, a standard library and also the 
defines that the user includes on its user.hpp file.

> 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. 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.
>
> The current report is more stable. You can change includes within the 
> same module without affecting it, and you can include another header 
> from the same module without affecting it. One can argue that it's not 
> "correct", but it's more useful. My module is on level 7, can I use 
> this? It's on level 4, so it'd probably not be much of a problem. That 
> other thing? It's on 9, so perhaps not.
>
>
I agree completely here with Peter. Tracking this level information is 
very useful. I would add that new dependencies on library at level 7 
should be possible but that would need reflexion and IMO should be 
posted on this list.

Once we reach to have a strict ordering we should preserve it. This 
doesn't mean that a library can not change of levels, but the changes 
must not add cycles.

Best,
Vicente