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