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-17 02:28:13

On Tue, Jun 17, 2014 at 9:08 AM, Robert Ramey <ramey_at_[hidden]> wrote:
>
> "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."
>
> The whole purpose of the exercise is to eliminate the requirement
> to checkout the complete boost tree.  If we're going to assume that
> this is going to continue indefinitely we can just stop right now
> and declare some sort of victory.

I wasn't assuming this will continue indefinitely. But obviously this
will continue to be the case until (a) there are tools for partial
Boost checkout and (b) there is actual benefit from it. Admittedly,
most work that had been done so far targets (b).

You may argue that without the tool we can't know what changes will be
beneficial. I think this is a chicken and egg problem, and someone
just has to start somewhere. Besides, some changes will be beneficial
regardless of the tool - for example, see recent discussions about
TypeTraits and TypeTraits.Core. As for moving headers to
sub-sub-modules, I would agree that the benefit of such changes
depends on the tool.

> The user needs a tool (which we might or might not have)

If we don't have it then all the modularization effort is pointless
and we should no longer waste our time with it. To my mind, its
presence is crucial to the success of the undertaking.

> which
> takes an *.cpp file as an argument and returns a list of libraries
> which that *.cpp file requires.  Of course this is more complicated
> that it might appear.   Each of the *.cpp files in he library
> which are used by the application has to be checked in the
> same manner.  And it's even more  complex.  For the DLL version
> of the date-time library, the author might have decided to package
> the serialization part in a separate DLL.  So one has to follow only
> the chain of calls according to which DLLs are actually going to
> get called.  Even in a static library, one will only want to follow
> the dependencies for the *.cpp files actually used.
>
> We're now starting down a path which will never arrive at
> a worthy destination.
>
> What want to end up with is a tool which looks like
>
> library-list <- tool *.cpp file list.
>
> so that users can download and ship the subset, only the subset,
> that their application requires.

Yes, the header-based tool (and for our purpose the cpp can be
considered as a header) is being discussed now in the adjacent thread.
I like the idea of generating dependencies based on the root cpp file.