-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: 17 June 2014 06:09 To: boost@lists.boost.org 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.
"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
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
+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. the proposition"
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 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
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
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
invoke the library? the libraries. 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 +44 01539 561830