anchor.diff:  non-recursive Makefiles) can take ten seconds to start building after
   changing one file.  Ninja is under a second.
   
  -This manual describes how to generate Ninja build files.  If you are
  -just attempting to use Ninja to build an existing project (or are
  -considering using Ninja to build your project), see
  -http://martine.github.com/ninja/[the home page] for more background.
  -
   Philosophical overview
   ~~~~~~~~~~~~~~~~~~~~~~
  +
  +Where other build systems are high-level languages, Ninja aims to be
  +an assembler.
   
   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
  
positive.code: painfully simple.  You must tell Ninja exactly what to do when you
  create your project's `.ninja` files.
  
  Comparison to GNU make
  ~~~~~~~~~~~~~~~~~~~~~~
  
  Ninja is closest in spirit and functionality to make.  But
  fundamentally, make has a lot of _features_: suffix rules, functions,
  built-in rules that e.g. search for RCS files when building source.
  Many projects find make alone adequate for their build problems.  In
  contrast, Ninja has almost no features; just those necessary to get
  builds correct while punting most complexity to generation of the
  ninja input files.  Ninja by itself is unlikely to be useful for most
  projects.
  
  Here are some of the features ninja adds to make.  (These sorts of
  features can often be implemented using more complicated Makefiles,
  but they are not part of make itself.)
  
  
negative.code: graph are not removed. This tool takes in account the +-v+ and the
  +-n+ options (note that +-n+ implies +-v+).
  
  
  
  Writing your own Ninja files
  ----------------------------
  
  The remainder of this manual is only useful if you are constructing
  Ninja files yourself: for example, if you're writing a meta-build
  system or supporting a new language.
  
  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.
  
  Syntax example
  ~~~~~~~~~~~~~~
  
  Here's a basic `.ninja` file that demonstrates most of the syntax.
  It will be used as an example for the following sections.
  
  ---------------------------------
  cflags = -Wall
  
  rule cc
    command = gcc $cflags -c $in -o $out
  
  build foo.o: cc foo.c
  ---------------------------------
  
  Variables
  ~~~~~~~~~
  Despite the non-goal of being convenient to write by hand, to keep
  build files readable (debuggable), Ninja supports declaring shorter
  reusable names for strings.  A declaration like the following
  
  ----------------
  cflags = -g
  ----------------
  
  can be used on the right side of an equals sign, dereferencing it with
  a dollar sign, like this:
  
  ----------------
  rule cc
    command = gcc $cflags -c $in -o $out
  ----------------
  
  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.  There is more on how shadowing works
  later in this document.
  
  Rules
  ~~~~~
  
  Rules declare a short name for a command line.  They begin with a line
  consisting of the `rule` keyword and a name for the rule.  Then
  follows an indented set of `variable = value` lines.
  
  The basic example above declares a new rule named `cc`, along with the
  command to run.  (In the context of a rule, the `command` variable is
  special and defines the command to run.  A full list of special
  variables is provided in <<ref_rule,the reference>>.)
  
  Within the context of a rule, two additional special variables are
  available: `$in` expands to the list of input files (`foo.c`) and
  `$out` to the output file (`foo.o`) for the command.
  
  
  Build statements
  ~~~~~~~~~~~~~~~~
  
  Build statements declare a relationship between input and output
  files.  They begin with the `build` keyword, and have the format
  +build _outputs_: _rulename_ _inputs_+.  Such a declaration says that
  all of the output files are derived from the input files.  When the
  output files are missing or when the inputs change, Ninja will run the
  rule to regenerate the outputs.
  
  The basic example above describes how to build `foo.o`, using the `cc`
  rule.
  
  In the scope of a `build` block (including in the evaluation of its
  associated `rule`), the variable `$in` is the list of inputs and the
  variable `$out` is the list of outputs.
  
  A build statement may be followed by an indented set of `key = value`
  pairs, much like a rule.  These variables will shadow any variables
  when evaluating the variables in the command.  For example:
  
  ----------------
  cflags = -Wall -Werror
  rule cc
    command = gcc $cflags -c $in -o $out
  
  # If left unspecified, builds get the outer $cflags.
  build foo.o: cc foo.c
  
  # But you can can shadow variables like cflags for a particular build.
  build special.o: cc special.c
    cflags = -Wall
  
  # The variable was only shadowed for the scope of special.o;
  # Subsequent build lines get the outer (original) cflags.
  build bar.o: cc bar.c
  
  ----------------
  
  For more discussion of how scoping works, consult <<ref_scope,the
  reference>>.
  
  If you need more complicated information passed from the build
  statement to the rule (for example, if the rule needs "the file
  extension of the first input"), pass that through as an extra
  variable, like how `cflags` is passed above.
  
  If the top-level Ninja file is specified as an output of any build
  statement and it is out of date, Ninja will rebuild and reload it
  before building the targets requested by the user.
  
  
  Generating Ninja files from code
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  
  `misc/ninja_syntax.py` in the Ninja distribution is a tiny Python
  module to facilitate generating Ninja files.  It allows you to make
  Python calls like `ninja.rule(name='foo', command='bar',
  depfile='$out.d')` and it will generate the appropriate syntax.  Feel
  free to just inline it into your project's build system if it's
  useful.
  
  
  More details
  ------------
  
  The `phony` rule
  ~~~~~~~~~~~~~~~~
  
  The special rule name `phony` can be used to create aliases for other
  targets.  For example:
  
  ----------------
  build foo: phony some/file/in/a/faraway/subdir/foo
  ----------------
  
  This makes `ninja foo` build the longer path.  Semantically, the
  `phony` rule is equivalent to a plain rule where the `command` does
  nothing, but phony rules are handled specially in that they aren't
  printed when run, logged (see below), nor do they contribute to the
  command count printed as part of the build process.
  
  `phony` can also be used to create dummy targets for files which
  may not exist at build time.  If a phony build statement is written
  without any dependencies, the target will be considered out of date if
  it does not exist.  Without a phony build statement, Ninja will report
  an error if the file does not exist and is required by the build.
  
  
  Default target statements
  ~~~~~~~~~~~~~~~~~~~~~~~~~
  
  By default, if no targets are specified on the command line, Ninja
  will build every output that is not named as an input elsewhere.
  You can override this behavior using a default target statement.
  A default target statement causes Ninja to build only a given subset
  of output files if none are specified on the command line.
  
  Default target statements begin with the `default` keyword, and have
  the format +default _targets_+.  A default target statement must appear
  after the build statement that declares the target as an output file.
  They are cumulative, so multiple statements may be used to extend
  the list of default targets.  For example:
  
  ----------------
  default foo bar
  default baz
  ----------------
  
  This causes Ninja to build the `foo`, `bar` and `baz` targets by
  default.
  
  
  The Ninja log
  ~~~~~~~~~~~~~
  
  For each built file, Ninja keeps a log of the command used to build
  it.  Using this log Ninja can know when an existing output was built
  with a different command line than the build files specify (i.e., the
  command line changed) and knows to rebuild the file.
  
  The log file is kept in the build root in a file called `.ninja_log`.
  If you provide a variable named `builddir` in the outermost scope,
  `.ninja_log` will be kept in that directory instead.
  
  
  Ninja file reference
  --------------------
  