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