Changes between Version 6 and Version 7 of HeaderModularization


Ignore:
Timestamp:
May 27, 2009, 5:07:04 PM (13 years ago)
Author:
Beman Dawes
Comment:

Add no code changes

Legend:

Unmodified
Added
Removed
Modified
  • HeaderModularization

    v6 v7  
    33== Goals/Objectives/Needs/Wants ==
    44
    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. Implies no separate checkout, update, commit, switch, etc. post-processing step.)
    7  3. Works well regardless of build engine, not just with 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. (Ignoring the dependency problem; that's orthogonal.)
    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 management, etc.) ((7) goes a long way to achieve this.)
    13  9. Works well with out-of-the box subversion, bjam, CMake, installers, and other tools we are likely to use.
    14  10. Supports test-on-demand and test-library-against-different-branch.
    15  11. Doesn't waste disk space excessively.
     5 0. Requires no Boost or user code changes.
     6 0. Single include path (-I...). Without a single include path, builds, IDE's, and other tools become unmanageable.
     7 0. Easy checkout, commit, merge, switch, and other source control operations. Implies no separate checkout, update, commit, switch, etc. post-processing step.)
     8 0. Works well regardless of build engine, not just with bjam or CMake.
     9 0. Doesn't break users existing scripts, IDE setups, etc. OK to break developers and release managers scripts.
     10 0. Easy library subset creation. (Ignoring the dependency problem; that's orthogonal.)
     11 0. Minimizes developer mistakes like failure to merge, commit, all files that changed.
     12 0. All maintenance occurs withing the library's libs/... directory. (Subset of previous entry, but important enough to list separately.)
     13 0. Easy scripting (inspect, unmerged changes, release management, etc.) (Previous entry goes a long way to achieve this.)
     14 0. Works well with out-of-the box subversion, bjam, CMake, installers, and other tools we are likely to use.
     15 0. Supports test-on-demand and test-library-against-different-branch.
     16 0. Doesn't waste disk space excessively.
    1617
    1718== Possible Approaches ==