Define everything in both stages

Now that packages and binaries are only built when needed, they need to
be defined in both stages in case something building in the main stage
needs something that was defined, but didn't need to be built in the
earlier stage.

Change-Id: I67704fba1d670e82218eba5ce91f0c01896557a2
2 files changed
tree: 4bc3dc281cb7f741287ae3cb1c988dc72e651cac
  1. bootstrap/
  2. bpfmt/
  3. bpmodify/
  4. deptools/
  5. gotestmain/
  6. gotestrunner/
  7. loadplugins/
  8. microfactory/
  9. parser/
  10. pathtools/
  11. proptools/
  12. tests/
  13. .gitignore
  14. .travis.fix-fork.sh
  15. .travis.gofmt.sh
  16. .travis.install-ninja.sh
  17. .travis.yml
  18. blueprint.bash
  19. blueprint_impl.bash
  20. Blueprints
  21. bootstrap.bash
  22. context.go
  23. context_test.go
  24. CONTRIBUTING.md
  25. doc.go
  26. glob.go
  27. LICENSE
  28. live_tracker.go
  29. mangle.go
  30. module_ctx.go
  31. ninja_defs.go
  32. ninja_strings.go
  33. ninja_strings_test.go
  34. ninja_writer.go
  35. ninja_writer_test.go
  36. package_ctx.go
  37. README.md
  38. scope.go
  39. singleton_ctx.go
  40. splice_modules_test.go
  41. unpack.go
  42. unpack_test.go
  43. visit_test.go
README.md

Blueprint Build System

Build Status

Blueprint is a meta-build system that reads in Blueprints files that describe modules that need to be built, and produces a 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 language 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.