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. Implies no separate checkout, update, commit, switch, etc. post-processing step.)
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 out-of-the box subversion, bjam, CMake, installers, and other tools we are likely to use.
10. Supports test-on-demand and test-library-against-different-branch.
11. Doesn't waste disk space excessively.

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.

Acknowledgements

Troy Straszheim, Vladimir Prus, Daniel James, Robert Ramey, Stefan Seefeld, and all the others who contributed modularization ideas.