anchor.diff:  
   `command` (_required_):: the command line to run.
   
  -`depfile`:: path to an optional `Makefile` that contains _implicit
  -  dependencies_.  Implicit dependencies are inputs to a build that are
  -  not given on the command line; the best example is how `gcc` has the
  -  `-M` family of flags to output the list of headers a given `.c` file
  +`depfile`:: path to an optional `Makefile` that contains extra
  +  _implicit dependencies_ (see the <<ref_dependencies,the reference on
  +  dependency types>>).  The best example is how `gcc` has the `-M`
  +  family of flags to output the list of headers a given `.c` file
     depends on.
   +
   ----
  
positive.code: Introduction
  ------------
  
  Ninja is yet another build system.  It takes as input a file
  describing interdependencies of files (typically source code and
  output executables) and orchestrates building them, _quickly_.
  
  Ninja joins a sea of other build systems.  Its distinguishing goal is
  to be fast.  It is born from my work on the Chromium browser project,
  which has well over 20,000 source files and whose other build systems
  (including one built from custom non-recursive Makefiles) take tens of
  seconds to start compiling after changing one file.
  
  Here are some of the design goals of Ninja:
  
  * very fast (i.e., instant) incremental builds, even for very large
    projects.
  
  * very little implicit policy; "explicit is better than implicit".
  
  * get dependencies correct, and in particular situations that are
    difficult to get right with Makefiles (e.g. outputs need an implicit
    dependency on the command line used to generate them; C source code
    need to be able to benefit from gcc's `-M` flags for header
    dependencies).
  
  * when convenience and speed are in conflict, prefer speed.
  
negative.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._
  
  To restate, Ninja is faster than other build systems because it is
  painfully simple.  You must tell Ninja exctly what to do 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`.
  
  Philosophical overview
  ~~~~~~~~~~~~~~~~~~~~~~
  
  Build systems get slow when they need to make decisions.  When you are
  in a edit-compile cycle you want it to be as fast as possible -- you
  want the build system to do the minimum work necessary to start
  the build immediately.
  
  Ninja contains the barest functionality necessary to describe
  arbitrary dependency graphs.  Its lack of syntax makes it impossible
  to express complex decisions.  Even build-time decisions like "should
  I build a debug-mode or release-mode binary?" belong in a
  ninja-file-generation step separate from your incremental builds.
  
  Conceptual overview
  ~~~~~~~~~~~~~~~~~~~
  