Gitiles
Code Review Sign In
review.blissroms.org / platform_build_blueprint / 1cda3fd3e4b1cbd4f9fed8ac59faa1be1954edff
commit1cda3fd3e4b1cbd4f9fed8ac59faa1be1954edff[log] [tgz]
authorColin Cross <ccross@android.com>Thu Jan 16 10:32:35 2020 -0800
committerColin Cross <ccross@android.com>Thu Jan 16 10:38:46 2020 -0800
tree7f161a186455608529b304067ab2e4a4c744a742
parentb92b466a463564b014e4c9b86f621bd4eab5fe63 [diff]
Fix primary builder reruns caused by globs

Globs produce a filelist using restat rules to avoid primary builder
reruns.  On the first execution of the primary builder the filelists
are written directly by the primary builder, so that the second
execution can restat them all but avoid rerunning the primary builder.
This wasn't working because the glob filelists were written after
the build.ninja file, but the build.ninja file depends on the
filelists.  Switching the order avoids the extra rerun.

Test: m nothing && m nothing
Change-Id: Ia8e0924598220d4ff34235907a8de2e3e03632df
1 file changed
tree: 7f161a186455608529b304067ab2e4a4c744a742
  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. go.mod
  29. LICENSE
  30. live_tracker.go
  31. mangle.go
  32. module_ctx.go
  33. module_ctx_test.go
  34. name_interface.go
  35. ninja_defs.go
  36. ninja_strings.go
  37. ninja_strings_test.go
  38. ninja_writer.go
  39. ninja_writer_test.go
  40. package_ctx.go
  41. README.md
  42. scope.go
  43. singleton_ctx.go
  44. splice_modules_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.