anchor.diff:  
   Its design was motivated by the games industry where projects are huge and
   iterative rebuilding common. In games, teams of 20-30 developers working on the
  -same multi-MLOC codebase is not uncommon. Each second wasted by a build system
  -to produce a incremental build wastes productivity. But Tundra works well for
  -smaller projects too.
  +same multi-MLOC codebase is not uncommon. Each second spent by a build system
  +not building wastes productivity, especially when there are thousands of builds
  +every day!
   
   === Design Philosphy ===
   
  -==== Simple and Fast ====
  +Here are some philosophical ideas and how they have influenced the design of
  +Tundra.
  +
  +==== Simple is Fast ====
   
   Tundra is written in ANSI C (C89), with very few files. Aside from Lua, there
   are no external dependencies. Most data structures in the C code are simple
  -arrays, either stack based or allocated from a linear allocator. All
  -allocations are discarded at once in pages when the program exits. This makes
  +arrays, either stack based or allocated from a linear allocator. This makes
   the code simple and the program fast as very little time is spent worrying
   about dynamic memory.
   
  +==== Support just enough ====
  +
  +Many modern build systems can sync code from a plethora of version control
  +systems, download files from HTTP and lots lots more. Tundra doesn't do any of
  +those things. It is a relatively simple command execution platform with a Lua
  +configuration frontend. A smaller scope means Tundra is easier to optimize.
  +
   ==== Utilize multi-core hardware ====
   
  -Almost all developers are using multi-core machines, so it is important that
  -the build system can run multiple jobs at once. But it is equally important to
  -utilize these cores to do other things like file signing and implicit
  -dependency scanning. Tundra is one of very few (if any) build systems that do
  -this whenever possible. This design choice give a nice speedup to incremental
  -builds.
  +It is important that a build system can run multiple jobs at once. But it is
  +equally important to utilize all cores to do other things like file signing and
  +implicit dependency scanning. Tundra is one of very few (if any) build systems
  +that do this whenever possible. This design gives a nice speedup to incremental
  +builds where most of the time is spent signing and checking file metadata.
   
   ==== Reliably support code generation ====
   
  -Most build systems work perfectly until you start generating source files
  -dynamically in the build process. If these files are then included into other
  -files many build systems start misbehaving, especially if multiple jobs are run
  -concurrently. This is very hard to diagnose and work around, leading to various
  -hacks and voodoo surrounding the build process.
  -
  -Tundra does away with this by adding the possibility of segmenting the build
  -into multiple, sequenced passes. Build jobs are only allowed to implicitly
  -depend on (that is, +#include+) files generated in previous passes. This keeps
  -file generation entirely predictable and it becomes easy to support a
  -multi-layered system where the code generation tool itself is built in a first
  -pass, it is run to generate output in a second pass and then the full build
  -commences. Tundra will still go wide within each pass, but each pass is fully
  -synchronous with regards to the others so using the +-j+ option is fully
  -supported.
  +Tundra is designed around the concept of build passes, which segment the input
  +dependency graph into serialized regions. Dependencies (even implicit
  +dependencies) can only point to nodes in the same or earlier passes. This
  +design makes it easy to reliably support code generation scenarios of arbitrary
  +complexity while still supporting fully multi-threaded execution whenever
  +possible.
   
   ==== Separate configuration and building ====
   
  
positive.code: the `TUNDRA_HOME` environment variable to the root directory of the tundra
  source distribution instead.
  
  == How Tundra works ==
  
  A Tundra build can divided into a few distinct phases:
  
negative.code: Default "HelloWorld"
  -------------------------------------------------------------------------------
  
  If we now run Tundra on this input, it will build our +HelloWorld+ executable.
  The output path shows that tundra has defaulted the variant to `debug` and the
  subvariant to `default`.
  
  -------------------------------------------------------------------------------
  $ tundra
  