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

Subject: Re: [boost] date_time -> serialization (Was: spirtit -> serialization)
From: Robert Ramey (ramey_at_[hidden])
Date: 2014-06-17 01:08:46

Andrey Semashev-2 wrote
> On Sun, Jun 15, 2014 at 9:21 PM, Paul A. Bristow
> <

> pbristow_at_.u-net

> > wrote:
>>> -----Original Message-----
>>> From: Boost [mailto:

> boost-bounces_at_.boost

> ] On Behalf Of Andrey
>> Semashev
>>> Sent: 15 June 2014 16:42
>>> To: 

> boost_at_.boost

>>> Subject: Re: [boost] date_time -> serialization (Was: spirtit ->
>> serialization)
>>>
> 
> 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.
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost

Not it's not acceptable.  git is already a little bit past the edge of what
we can
stand as far as adding complexity.  

"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.

The whole "optional component issue" hasn't been properly
considered.  The key miss-step is in the idea that one library
is dependent upon another library.  This concept cannot be
defined.  It is our equivalent to an "undecidable proposition"

As an example take the date-time library.  For a user
who is just going to invoke the basic functions - the
serialization implementation should not be considered while
for users that do use these functions it has to be.

So you say - OK - we'll just make another submodule
date-time/serialization.  At this point you've basically
given up on the idea that there is an unambiguous answer
to the question - is the date-time library dependent upon
the serialization library?  the real answer is - can't say
without more information.

So now you say - well, that's all theoretical BS if we just
make another submodule - we'll avoid the whole problem.

But what about a user who needs to run tests on the one
or other of the libraries.  For example, the serialization library
tests depend upon system and file system.  The date-time
library might depend upon boost test.  

Upshot is that it makes no sense to argue that library X is
dependent upon library Y without considering a specific application.

So once you've eliminated circular dependencies - which is bug
you should stop.

The user needs a tool (which we might or might not have) 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.

Robert Ramey

--
View this message in context: http://boost.2283326.n4.nabble.com/modularization-spirtit-serialization-tp4664074p4664250.html
Sent from the Boost - Dev mailing list archive at Nabble.com.