- Requires no Boost or user code changes.
- Single include path (-I...). Without a single include path, builds, IDE's, and other tools become unmanageable.
- Easy checkout, commit, merge, switch, and other source control operations. Implies no separate checkout, update, commit, switch, etc. post-processing step.)
- Works well regardless of build engine, not just with bjam or CMake.
- Doesn't break users existing scripts, IDE setups, etc. OK to break developers and release managers scripts.
- Easy library subset creation. (Ignoring the dependency problem; that's orthogonal.)
- Minimizes developer mistakes like failure to merge, commit, all files that changed.
- All maintenance occurs withing the library's libs/... directory. (Subset of previous entry, but important enough to list separately.)
- Easy scripting (inspect, unmerged changes, release management, etc.) (Previous entry goes a long way to achieve this.)
- Works well with out-of-the box subversion, bjam, CMake, installers, and other tools we are likely to use.
- Supports test-on-demand and test-library-against-different-branch.
- Doesn't waste disk space excessively.
- Status quo.
- Copy header directories to ../../boost via post-svn step.
- Move header directories to ../../boost via post-svn step.
- Forwarding headers (in svn).
- Forwarding headers via post-svn step.
- Symlinks from root/boost/... to boost-root/libs/... via post-svn step.
- Hard links from root/boost/... to boost-root/libs/... via post-svn step.
- Move (permanently) each library's root/libs/libname contents into root/boost/libname for the library.
Troy Straszheim, Vladimir Prus, Daniel James, Robert Ramey, Stefan Seefeld, and all the others who contributed modularization ideas.