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

On Sun, Jun 15, 2014 at 9:21 PM, Paul A. Bristow wrote:

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Andrey Semashev Sent: 15 June 2014 16:42 To: boost@lists.boost.org Subject: Re: [boost] date_time -> serialization (Was: spirtit -> serialization)

On Sun, Jun 15, 2014 at 7:16 PM, Paul A. Bristow 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.