Changes between Version 1 and Version 2 of HeaderModularization

Timestamp:

May 27, 2009, 3:34:25 PM (13 years ago)

Author:

Beman Dawes

Comment:

Refine wording

HeaderModularization

@@ -5 +5 @@
  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; remember that users don't all use bjam or CMake. 
+ 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.
+ 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 mgt, etc.) ((7) goes a long way to achieve this.)
+ 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-other-branch.
+ 10. Supports test-on-demand and test-library-against-different-branch.