anchor.diff:  * Rules can provide shorter descriptions of the command being run, so
     you can print e.g. `CC foo.o` instead of a long command line while
     building.
  +
  +* Builds are always run in parallel, based by defaulton the number of
  +  CPUs your system has.  Underspecified build dependencies will result
  +  in incorrect builds.
   
   * Command output is always buffered.  This means commands running in
     parallel don't interleave their output, and when a command fails we
  
positive.code: 
  Ninja contains the barest functionality necessary to describe
  arbitrary dependency graphs.  Its lack of syntax makes it impossible
  to express complex decisions.  Instead, Ninja is intended to be used
  with a separate program generating its input files.  The generator
  program (like the `./configure` found in autotools projects) can
  analyze system dependencies and make as many decisions as possible up
  front so that incremental builds stay fast.  Going beyond autotools,
  even build-time decisions like "which compiler flags should I use?"
  or "should I build a debug or release-mode binary?"  belong in the
  `.ninja` file generator.
  
  Conceptual overview
  ~~~~~~~~~~~~~~~~~~~
  
  Ninja evaluates a graph of dependencies between files, and runs
  whichever commands are necessary to make your build target up to date.
  If you are familiar with Make, Ninja is very similar.
  
  A build file (default name: `build.ninja`) provides a list of _rules_
  -- short names for longer commands, like how to run the compiler --
  along with a list of _build_ statements saying how to build files
  using the rules -- which rule to apply to which inputs to produce
  which outputs.
  
  Conceptually, `build` statements describe the dependency graph of your
  project, while `rule` statements describe how to generate the files
  along a given edge of the graph.
  
  Design goals
  ~~~~~~~~~~~~
  
  Here are some of the design goals of Ninja:
  
  * very fast (i.e., instant) incremental builds, even for very large
    projects.
  
negative.code:   produced the failure.
  
  
  Using Ninja for your project
  ----------------------------
  
  If your project is small, Ninja's speed impact is likely unnoticable.
  Some build timing numbers are included below.  (However, even for
  small projects it sometimes turns out that Ninja's limited syntax
  forces simpler build rules that result in faster builds.)  Another way
  to say this is that if you're happy with the edit-compile cycle time
  of your project already then Ninja won't help.
  
  There are many other build systems that are more user-friendly or
  featureful than Ninja itself.  For some recomendations: the Ninja
  author found http://gittup.org/tup/[the tup build system] influential
  in Ninja's design, and thinks https://github.com/apenwarr/redo[redo]'s
  design is quite clever.
  
  Ninja's benefit comes from using it in conjunction with a smarter
  meta-build system.
  
  http://code.google.com/p/gyp/[gyp]:: The meta-build system used to
  generate build files for Google Chrome.  gyp can generate Ninja files
  for Linux and Mac and is used by many Chrome developers.  See the
  http://code.google.com/p/chromium/wiki/NinjaBuild[Chromium Ninja
  documentation for more details].  gyp is relatively unpopular outside
  of the Chrome and v8 world.
  
  * For Chrome (~30k source files), Ninja reduced no-op builds from
    around 15 seconds to under one second.
  * https://plus.sandbox.google.com/108996039294665965197/posts/SfhrFAhRyyd[A
    Mozilla developer compares build systems]: "While chromium's full
    build is 2.15x slower than firefox's, a nop build is 78.2x faster!
    That is really noticeable during development. No incremental build
    of firefox can be faster than 57.9s, which means that in practice
    almost all of them will be over a minute."
  
  http://www.cmake.org/[CMake]:: A widely used meta-build system that
  can generate Ninja files as of version 2.8.8.
  
  * For building Blender, one user reported "Single file rebuild is 0.97
    sec, same on makefiles was 3.7sec."
  * For building LLVM on Windows, one user reported no-op build times:
    "ninja: 0.4s / MSBuild: 11s / jom: 53s".
  
  others:: Ninja ought to fit perfectly into other meta-build software
  like http://industriousone.com/premake[premake].  If you do this work,
  please let us know!
  
  
  Running Ninja
  ~~~~~~~~~~~~~
  
  Run `ninja`.  By default, it looks for a file named `build.ninja` in
  the current directory and builds all out-of-date targets.  You can
  specify which targets (files) to build as command line arguments.
  
  `ninja -h` prints help output.  Many of Ninja's flags intentionally
  match those of Make; e.g `ninja -C build -j 20` changes into the
  `build` directory and runs 20 build commands in parallel.  (Note that
  Ninja defaults to running commands in parallel anyway, so typically
  you don't need to pass `-j`.)
  
  
  Environment variables
  ~~~~~~~~~~~~~~~~~~~~~
  
  Ninja supports one environment variable to control its behavior.
  
  `NINJA_STATUS`:: The progress status printed before the rule being run.
  Several placeholders are available:
  * `%s`: The number of started edges.
  * `%t`: The total number of edges that must be run to complete the build.
  * `%r`: The number of currently running edges.
  * `%u`: The number of remaining edges to start.
  * `%f`: The number of finished edges.
  * `%%`: A plain `%` character.
  * The default progress status is `"[%s/%t] "` (note the trailing space
  to separate from the build rule). Another example of possible progress status
  could be `"[%u/%r/%f] "`.
  
  Extra tools
  ~~~~~~~~~~~
  
  The `-t` flag on the Ninja command line runs some tools that we have
  found useful during Ninja's development.  The current tools are:
  