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 ->
> >>> 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
+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
> Boost distribution, the effect of our work will be relatively small. But our
> modular Boost, which includes modular distribution, as I understand it."
> The whole purpose of the exercise is to eliminate the requirement to checkout
> 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.
> concept cannot be defined. It is our equivalent to an "undecidable
> As an example take the date-time library. For a user who is just going to
> basic functions - the serialization implementation should not be considered
> users that do use these functions it has to be.
> So you say - OK - we'll just make another submodule date-time/serialization.
> point you've basically given up on the idea that there is an unambiguous
> the question - is the date-time library dependent upon the serialization
> real answer is - can't say without more information.
> So now you say - well, that's all theoretical BS if we just make another
> we'll avoid the whole problem.
> But what about a user who needs to run tests on the one or other of the
> For example, the serialization library tests depend upon system and file
> date-time library might depend upon boost test.
> Upshot is that it makes no sense to argue that library X is dependent upon
> without considering a specific application.
> So once you've eliminated circular dependencies - which is bug you should
At least until we see some clear signs that we are going get benefits from
PS Meanwhile we *must* get a release out.
--- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 01539 561830
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk