Split "variant" terminology into "variant" and "variation"

"Variant" has been used to mean two slightly concepts in Blueprint.
The first and most obvious is a variant of a module, meaning a list
of all the ways that on version of a module differs from other
versions of the same modules, for example "arch:arm, link:static".
The other is for the specific way that a version of a module differs,
"arch:arm".

Rename all of uses of "variant" as the second meaning to "variation",
and update the documentation to clarify "variant" vs. "variation".
This modifies the build logic api to convert CreateVariants to
CreateVariations.

Change-Id: I789ef209ae6ddd39ec12e0c032f9f47f86698fe6
2 files changed
tree: 2da379add1f0e8e986f23833aef5b47083d3e2f1
  1. bootstrap/
  2. bpfmt/
  3. bpmodify/
  4. deptools/
  5. parser/
  6. pathtools/
  7. proptools/
  8. Blueprints
  9. bootstrap.bash
  10. build.ninja.in
  11. context.go
  12. context_test.go
  13. doc.go
  14. LICENSE
  15. live_tracker.go
  16. mangle.go
  17. module_ctx.go
  18. ninja_defs.go
  19. ninja_strings.go
  20. ninja_strings_test.go
  21. ninja_writer.go
  22. ninja_writer_test.go
  23. package_ctx.go
  24. README.md
  25. scope.go
  26. singleton_ctx.go
  27. unpack.go
  28. unpack_test.go
README.md

Blueprint Build System

Blueprint is a meta-build system that reads in Blueprints files that describe modules that need to be built, and produces a Ninja (http://martine.github.io/ninja/) manifest describing the commands that need to be run and their dependencies. Where most build systems use built-in rules or a domain-specific langauge to describe the logic for converting module descriptions to build rules, Blueprint delegates this to per-project build logic written in Go. For large, heterogenous projects this allows the inherent complexity of the build logic to be maintained in a high-level language, while still allowing simple changes to individual modules by modifying easy to understand Blueprints files.