anchor.diff:  
   The included `bootstrap.sh` should hopefully produce a working `ninja`
   binary, by first blindly compiling all non-test files together then
  -re-building ninja using itself.
  +re-building Ninja using itself.
   
   Usage is currently just
   
  
positive.code:   generate your ninja files using another program_.  This is how we
    can sidestep many policy decisions.
  
  * built-in rules. _Out of the box, ninja has no rules for
    e.g. compiling C code._
  
  * build-time customization of the build. _Options belong in
    the program that generates the ninja files_.
  
  * build-time decision-making ability such as conditionals or search
    paths. _Making decisions is slow.  Ninja strikes its target without
    any hesitation._
  
  To restate, Ninja manages to be simpler and faster than other build
  systems by being much more stupid.  It has no built-in knowledge of
  how to build C source, or link libraries, or install binaries.
  
  You instead decide this policy when you create your project's `.ninja`
  files.  Customization and configuration are out of scope; instead you
  should provide customization in the system that generates your
  `.ninja` files, like how autoconf provides `./configure`.
  
  Conceptual overview
  ~~~~~~~~~~~~~~~~~~~
  
negative.code: 
  Build dependencies
  ~~~~~~~~~~~~~~~~~~
  [[ref_dependencies]]
  
  There are three types of build dependencies which are subtly different.
  
  1. _Explicit dependencies_, as listed in a build line.  These are
     available as the `$in` variable in the rule.  Changes in these files
     cause the output to be rebuilt; if these file are missing and
     Ninja doesn't know how to build them, the build is aborted.
  +
  This is the standard form of dependency to be used for e.g. the
  source file of a compile command.
  
  2. _Implicit dependencies_, either as picked up from
     a `depfile` attribute on a rule or from the syntax +| _dep1_
     _dep2_+ on the end of a build line.  Changes in these files cause
     the output to be rebuilt; if they are missing, they are just
     skipped.
  +
  This is for expressing dependencies that don't show up on the
  command line of the command; for example, for a rule that runs a
  script, the script itself should be an implicit dependency, as
  changes to the script should cause the output to rebuild.
  
  3. _Order-only dependencies_, expressed with the syntax +|| _dep1_
     _dep2_+ on the end of a build line.  When these are missing, the
  