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

Subject: Re: [boost] date_time -> serialization (Was: spirtit -> serialization)
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2014-06-19 09:10:19

> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Robert Ramey
> Sent: 17 June 2014 06:09
> To: boost_at_[hidden]
> Subject: Re: [boost] date_time -> serialization (Was: spirtit ->
serialization)
> 
> >>> 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.
> > _______________________________________________
> 
> Not it's not acceptable. 

> git is already a little bit past the edge of what we can stand as far as
adding complexity.

+1 - And on top of that, some 'snags' with the hard/symlinks are emerging. 

At the very least, they make using the MS IDE (and others?) error prone.

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

+1

At least until we see some clear signs that we are going get benefits from
Modular Boost.

Paul

PS Meanwhile we *must* get a release out.

---
Paul A. Bristow
Prizet Farmhouse
Kendal UK LA8 8AB
[phone]