Andrey Semashev-2 wrote
On Sun, Jun 15, 2014 at 9:21 PM, Paul A. Bristow <
pbristow@.u-net
> wrote:
-----Original Message----- From: Boost [mailto:
boost-bounces@.boost
] On Behalf Of Andrey
Semashev
Sent: 15 June 2014 16:42 To:
boost@.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-tp46... Sent from the Boost - Dev mailing list archive at Nabble.com.