No description
ab223a512b
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 |
||
|---|---|---|
| bootstrap | ||
| bpfmt | ||
| bpmodify | ||
| deptools | ||
| gotestmain | ||
| gotestrunner | ||
| loadplugins | ||
| microfactory | ||
| parser | ||
| pathtools | ||
| proptools | ||
| tests | ||
| .gitignore | ||
| .travis.fix-fork.sh | ||
| .travis.gofmt.sh | ||
| .travis.install-ninja.sh | ||
| .travis.yml | ||
| blueprint.bash | ||
| blueprint_impl.bash | ||
| Blueprints | ||
| bootstrap.bash | ||
| context.go | ||
| context_test.go | ||
| CONTRIBUTING.md | ||
| doc.go | ||
| glob.go | ||
| glob_test.go | ||
| LICENSE | ||
| live_tracker.go | ||
| mangle.go | ||
| module_ctx.go | ||
| name_interface.go | ||
| ninja_defs.go | ||
| ninja_strings.go | ||
| ninja_strings_test.go | ||
| ninja_writer.go | ||
| ninja_writer_test.go | ||
| package_ctx.go | ||
| README.md | ||
| scope.go | ||
| singleton_ctx.go | ||
| splice_modules_test.go | ||
| unpack.go | ||
| unpack_test.go | ||
| visit_test.go | ||
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 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.