Header Modularization

Goals/Objectives/Needs/Wants

1. Single include path (-I...). Without a single include path, builds, IDE's, and other tools become unmanageable.
2. Easy checkout, commit, merge, switch, and other source control operations.
3. Works well regardless of build engine, not just with bjam or CMake.
4. Doesn't break users existing scripts, IDE setups, etc. OK to break developers and release managers scripts.
5. Easy library subset creation. (Ignoring the dependency problem; that's orthogonal.)
6. Minimizes developer mistakes like failure to merge, commit, all files that changed.
7. All maintenance occurs withing the library's libs/... directory. (Subset of (6), but important enough to list separately.)
8. Easy scripting (inspect, unmerged changes, release management, etc.) ((7) goes a long way to achieve this.)
9. Works well with installers.
10. Supports test-on-demand and test-library-against-different-branch.

Possible Approaches

1. Status quo.
2. svn:externals.
3. Copy header directories to ../../boost via post-svn step.
4. Move header directories to ../../boost via post-svn step.
5. Forwarding headers (in svn).
6. Forwarding headers via post-svn step.
7. Symlinks from root/boost/... to boost-root/libs/... via post-svn step.
8. Hard links from root/boost/... to boost-root/libs/... via post-svn step.
9. Move (permanently) each library's root/libs/libname contents into root/boost/libname for the library.