On Tue, Jun 17, 2014 at 9:08 AM, Robert Ramey
"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.
I wasn't assuming this will continue indefinitely. But obviously this will continue to be the case until (a) there are tools for partial Boost checkout and (b) there is actual benefit from it. Admittedly, most work that had been done so far targets (b). You may argue that without the tool we can't know what changes will be beneficial. I think this is a chicken and egg problem, and someone just has to start somewhere. Besides, some changes will be beneficial regardless of the tool - for example, see recent discussions about TypeTraits and TypeTraits.Core. As for moving headers to sub-sub-modules, I would agree that the benefit of such changes depends on the tool.
The user needs a tool (which we might or might not have)
If we don't have it then all the modularization effort is pointless and we should no longer waste our time with it. To my mind, its presence is crucial to the success of the undertaking.
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.
Yes, the header-based tool (and for our purpose the cpp can be considered as a header) is being discussed now in the adjacent thread. I like the idea of generating dependencies based on the root cpp file.