Re: [boost] date_time -> serialization (Was: spirtit -> serialization)

Subject: Re: [boost] date_time -> serialization (Was: spirtit -> serialization)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-06-15 14:00:50

On Sun, Jun 15, 2014 at 9:21 PM, Paul A. Bristow
<pbristow_at_[hidden]> wrote:
>> -----Original Message-----
>> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Andrey
> Semashev
>> Sent: 15 June 2014 16:42
>> To: boost_at_[hidden]
>> Subject: Re: [boost] date_time -> serialization (Was: spirtit ->
> serialization)
>>
>> On Sun, Jun 15, 2014 at 7:16 PM, Paul A. Bristow <pbristow_at_[hidden]>
>> wrote:
>> >
>> > If someone is using Serialisation then isn't there a very high
>> > probability that they are also using DateTime?
>>
>> I'd say there isn't. I'd say even if a user uses both Serialization and
> DateTime this
>> doesn't mean he uses Serialization support in DateTime.
>
> Ah  - I had misunderstood  DateTime did not imply Serialization support in
> DateTime.

I'm not sure I understand you. DateTime and its support for
Serialization live in the same git repository, so when you checkout
DateTime you get everything. The problem is that currently there is no
way to separate core DateTime functionality from Serialization
support. The proposal was to move these support headers into another
subdirectory inside the DateTime git submodule. By the build system,
this would be equivalent to a new submodule. (BTW, we should introduce
a new term for this; otherwise we will get confused all the time). As
a result you will still checkout everything of DateTime when you
checkout its git repo, but the dependency graph will have two nodes
for it - DateTime and DateTime.Serialization. If you don't use
DateTime.Serialization part, you will not have to checkout
Serialization as well to get the usable Boost subset.

> However, does my general point is that many users are already pulling in a large
> part of Boost, which may mean that your efforts may not be as useful in practice
> as in theory?

As long as people keep checking out the complete Boost tree and use
monolithic Boost distribution, the effect of our work will be
relatively small. But our goal is modular Boost, which includes
modular distribution, as I understand it.

>> > Sub-sub-modules sound Very Evil to me.
>>
>> Why?
>
> More complicated file layout.

Agree, this is inconvenient. But as long as there is no better
solution, this is an acceptable evil.

> Will there be a sub-module GIT repo?  Already getting sub-modules updated is
> troublesome.

No, sub-sub-modules reside in the same git repo. Unless the
maintainers want otherwise, of course, and I don't remember anyone
requesting that.