anchor.diff:  Comparison to GNU make
   ~~~~~~~~~~~~~~~~~~~~~~
   
  -* Ninja lacks most of the features of Makefiles: conditionals, functions,
  -  implicit rules.
  +Fundamentally, make has a lot of _features_: suffix rules, functions,
  +built-in rules that look for RCS files when building.  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.
  +
  +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.)
   
   * A Ninja rule may point at a path for extra implicit dependency
     information.  This makes it easy to get header dependencies correct
  
positive.code: 
  `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.
  +
  ----
  rule cc
  
negative.code: 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.
  
  
  Ninja file reference
  --------------------
  A file is a series of declarations.  A declaration can be one of:
  
  1. A rule declaration, which begins with +rule _rulename_+, and
     then has a series of indented lines defining variables.
  
  2. A build edge, which looks like +build _output1_ _output2_:
     _rulename_ _input1_ _input2_+. +
     Implicit dependencies may be tacked on the end with +|
     _dependency1_ _dependency2_+.
     Order-only dependencies may be tacked on the end with +||
     _dependency1_ _dependency2_+.
  
  3. Variable declarations, which look like +_variable_ = _value_+.
  