Google Git
Sign in
android / platform / build / blueprint / ab223a512bbf0e8ca3012a7425e15c0210c7b1a6
commitab223a512bbf0e8ca3012a7425e15c0210c7b1a6[log] [tgz]
authorDan Willemsen <dwillemsen@google.com>Thu Jul 05 21:56:59 2018 -0700
committerDan Willemsen <dwillemsen@google.com>Fri Jul 06 10:39:38 2018 -0700
treeedbab2f3b489fcbe39253db2c63f0d59b428d41e
parent9cbbb8b91d7642abd130af55f0b6b894ab707cac [diff]
Run globs during earlier bootstrap phases

Instead of sometimes re-running minibp/the primary builder during the
next phase, run bpglob earlier to check dependencies.

We've run into issues where the environment is slightly different
between bootstrapping phase and the main build phase. It's also a
problem because our primary builder (Soong) exports information used by
another tool (Kati) that runs in between the bootstrapping phases and
the main phase. When Soong would run in the main phase, it could get out
of sync, and would require the build to be run again.

To do this, add a "subninja" include a build-globs.ninja file to each
build.ninja file. The first time, this will be an empty file, but we'll
always run minibp / the primary builder anyway. When the builder runs,
in addition to writing a dependency file, write out the
build-globs.ninja file with the rules to run bpglob.

Since bpglob may need to be run very early, before it would normally be
built, build it with microfactory.

Change-Id: I89fcd849a8729e892f163d40060ab90b5d4dfa5d
14 files changed
tree: edbab2f3b489fcbe39253db2c63f0d59b428d41e
  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. glob_test.go
  28. LICENSE
  29. live_tracker.go
  30. mangle.go
  31. module_ctx.go
  32. name_interface.go
  33. ninja_defs.go
  34. ninja_strings.go
  35. ninja_strings_test.go
  36. ninja_writer.go
  37. ninja_writer_test.go
  38. package_ctx.go
  39. README.md
  40. scope.go
  41. singleton_ctx.go
  42. splice_modules_test.go
  43. unpack.go
  44. unpack_test.go
  45. 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.