anchor.diff:  - Load toolsets, syntax files and other information as required by the configuration script
   - Run the referred +Units+ file in syntax mode to define the project's build units
   - Parse the resulting declarations and generate DAG nodes
  -- Pass the DAG to the native build engine
  -
  -== The +tundra.lua+ file ==
  +- Pass the DAG to the native build engine for building
  +
  +== The tundra.lua file ==
   
   The file +tundra.lua+ is read by Tundra when you invoke it. This is a regular
   Lua source file. Its purpose is to call the global +Build+ function with a
  
positive.code: 
  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.
  
  === Design Philosphy ===
  
  ==== Simple and 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
  the code simple and the program fast as very little time is spent worrying
  about dynamic memory.
  
  ==== 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.
  
  ==== 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.
  
  ==== Separate configuration and building ====
  
  
negative.code: the `TUNDRA_HOME` environment variable to the root directory of the tundra
  source distribution instead.
  
  == A bit of Tundra nomenclature ==
  
  Here are some terms and definitions used in Tundra and elsewhere in this document:
  
  - *configuration* - A two-tuple value separated with a dash; usually in the
    format `host-toolset`. Two common examples are `win32-msvc` and `linux-gcc`.
    Configurations can load one or more toolsets.
  
  - *variant* - A variant of a configuration; such as a with or without debugging
    information. Variants serve as tags to filter settings against. By default,
    tundra provides three variants: `debug`, `production` and `release` but these
    can be overridden as desired.
  
  - *subvariant* - An additional axis of separation that is orthagonal to
    variants but serve the same purpose. By default there is only one subvariant
    called `default`. Tundra itself uses two subvariants to select between build with
    Lua files embedded (`standalone`) or with Lua files in the file system (`dev`).
  
  - *build id* - A four-tuple `host-toolset-variant-subvariant` used to fully
    identify a build. Available through `BUILD_ID` in the unit environment.
  
  - *unit* - A high-level declaration of a piece of software. Unit declarations
    appear as a syntactic elements in unit input files. Static and dynamic
    libraries, programs and .NET assemblies are examples of units. Units are passed
    through the `nodegen` layer to produce dependency graphs from the declarations.
  
  - *environment* - A data structure with key-value mappings used to track
    configuration data inside Tundra. Sometimes refers to the OS environment.
  
  - *toolset* - A set of commands (e.g. compiler, linker and so on) that can be
    used to produce output files. Multiple toolsets can be loaded into a single
    configuration as long as there is no overlap in their settings, that is, a .NET
    toolset like `mono` can coexists with something like `gcc`, but you can't have
    two `gcc`-style toolsets loaded into the same configuration at once. Use different
    configurations for that.
  
  == How Tundra works ==
  
  A Tundra build can divided into a few distinct phases:
  