anchor.diff:  project, while `rule` statements describe how to generate the files
   along a given edge of the graph.
   
  -Semantic differences from make
  -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  -
  -* A rule may point at a path for extra implicit dependency
  +Comparison to GNU make
  +~~~~~~~~~~~~~~~~~~~~~~
  +
  +* Ninja lacks most of the features of Makefiles: conditionals, functions,
  +  implicit rules.
  +
  +* A Ninja rule may point at a path for extra implicit dependency
     information.  This makes it easy to get header dependencies correct
     for C/C++ code.
   
  
positive.code: 
  Build 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 should be an implicit dependency.
  
  3. _Order-only dependencies_, expressed with the syntax +|| _dep1_
     _dep2_+ on the end of a build line.  When these are missing, the
  
negative.code: 
  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.
  
  Usage is currently just
  
  