Google Git
Sign in
fuchsia / third_party / blueprint / d79f1af7423e0ef7a13573efdae5100a57fabc82
commitd79f1af7423e0ef7a13573efdae5100a57fabc82[log] [tgz]
authorDan Willemsen <dwillemsen@google.com>Wed Dec 09 18:03:13 2015 -0800
committerDan Willemsen <dwillemsen@google.com>Thu Dec 10 16:18:15 2015 -0800
tree594f1ce143a57eb31aab0bc96ba83c77097b5a47
parenteb97a6e7a1afa6d4817545bec3304e906ecc35f7 [diff]
Add build wrapper to do stage selection before ninja

This wrapper script can be used instead of ninja to ensure the build
won't get stuck building the primary builder.

An example of when this would happen:

1. Do a successful build
2. Sync/make a change in the primary builder (soong, etc) that depends
   on a blueprint change.
3. The next build would notice that change, and rewind to the primary
   stage to rebuild the builder. That build would fail.
4. Sync/fix the blueprint code.
5. The next build would still fail. The bootstrap stage would need to
   be run in order to fix the primary stage, but we're still stuck in the
   primary stage. The only way to switch stages is to successfully
   complete everything required to choose the next stage.

This generally isn't a problem in the main stage, since there is no code
being built in the dependency chain leading up to stage selection.

Any existing wrappers (like soong) can execute this wrapper (optionally
skipping ninja execution) if they're worried about the above situation.
This isn't strictly required -- running ninja directly will still work
in most cases, you'll just need to re-run bootstrap.bash if you get into
a bad state.

Change-Id: I5901d7240a1daa388a786ceb1c8259502fc14058
8 files changed
tree: 594f1ce143a57eb31aab0bc96ba83c77097b5a47
  1. bootstrap/
  2. bpfmt/
  3. bpmodify/
  4. choosestage/
  5. deptools/
  6. gotestmain/
  7. gotestrunner/
  8. loadplugins/
  9. parser/
  10. pathtools/
  11. proptools/
  12. tests/
  13. .gitignore
  14. .travis.fix-fork.sh
  15. .travis.install-ninja.sh
  16. .travis.yml
  17. blueprint.bash
  18. Blueprints
  19. bootstrap.bash
  20. build.ninja.in
  21. context.go
  22. context_test.go
  23. context_test_Blueprints
  24. CONTRIBUTING.md
  25. doc.go
  26. LICENSE
  27. live_tracker.go
  28. mangle.go
  29. module_ctx.go
  30. ninja_defs.go
  31. ninja_strings.go
  32. ninja_strings_test.go
  33. ninja_writer.go
  34. ninja_writer_test.go
  35. package_ctx.go
  36. README.md
  37. scope.go
  38. singleton_ctx.go
  39. splice_modules_test.go
  40. unpack.go
  41. unpack_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.