On Tue, May 8, 2012 at 12:15 PM, Jeremiah Willcock <jewillco@osl.iu.edu> wrote:
On Tue, 8 May 2012, Dave Abrahams wrote:
Hi All,
As we head toward a modularized Boost, Daniel Pfeifer we on the Ryppl project would like confirmation that we've correctly (or at least sensibly, when there's no obvious "correct") identified the module boundaries in Boost's monolithic SVN repository. If library authors could take a few moments to examine the contents of your library's repo at https://github.com/boost-lib, and let us know, we'd be most grateful.
graph and graph_parallel are fine; property_map is reasonable except that the things that are in include/boost/pending should be in that directory in graph/ instead. Does it make sense to modularize utility to split things like enable_if out into separate trees like you are doing at the top level of Boost?
Daniel Pfeifer and the other Ryppl folks have already done a some minor rationalization where a few minor components were clearly in the wrong spot. See boost-root/libs/core. Utility may well need some further refactoring, which can take the form of additional sub-directories as well as additional sub-modules. Years ago John Maddock had some guidelines on directory tree branchiness. The idea was that both too few and too many were less than helpful. I'm guessing sub-modules are similar - too few and the full benefits of modularization are not obtained, too many and confusion or other costs may overwhelm benefits. --Beman