anchor.diff:  extension of the first input"), pass that through as an extra
   variable, like how `cflags` is passed above.
   
  +Generating Ninja files
  +----------------------
  +
  +A work-in-progress patch to http://gyp.googlecode.com[gyp, the system
  +used to generate build files for the Chromium browser] to generate
  +ninja files for Linux is included in the source distribution.
  +
  +Conceptually, you could coax Automake into producing ninja files as
  +well, but I haven't tried it.  It may very well be the case that most
  +projects use too much Makefile syntax in their `.am` files for this to
  +work.
  +
   
   Ninja file reference
   --------------------
  
positive.code: Variables can also be referenced using curly braces like `${in}`.
  
  Variables might better be called "bindings", in that a given variable
  cannot be changed, only shadowed.  More on how shadowing works
  follows.
  
  
  
  Rules
  ~~~~~
  
negative.code: seconds to start building after changing one file.  Ninja is under a
  second.
  
  
  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 figure out
  what needs to be built immediately.
  
  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 a build a debug or release-mode binary?"  belong in the
  ninjafile 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 ouputs.
  
  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
  ~~~~~~~~~~~~
  
  