| commit | b6d88a4f0a6f59017dd84395b2c5b209903d90a3 | [log] [tgz] |
|---|---|---|
| author | Dan Willemsen <dwillemsen@google.com> | Tue Nov 01 17:12:28 2016 -0700 |
| committer | Dan Willemsen <dwillemsen@google.com> | Wed Nov 02 13:10:27 2016 -0700 |
| tree | f22759e4993c3097938c03ee512f92ccbd336301 | |
| parent | a2d14b7a408578ff84a788b7ab45e7f6207b110b [diff] |
Allow build.ninja regeneration (fix Soong globs) Soong (and soon, Blueprint) embeds the results of filesystem globs into the build.ninja, and uses a helper tool to detect when the glob changes and we need to rebuild the build.ninja file. This is more flexible than listing the affected directories in the depfiles, since it can check to see if a file we actually cared about was added, instead of re-running anytime any file was added/removed (which happens on atomic file modifications as well). My recent bootstrap simplification broke this, since the helper rules are in the main build.ninja, but I removed the ability to regenerate that file from itself. So keep the current model, but add a rule into the primary and main stages that allow themselves to re-run their generator and write out a new build.ninja file if necessary. The actual build rules of the generator aren't necessary, since we already built them in the previous stage. Change-Id: Ib51245920b2ec3ee5306c0c269361a5a8733caa8
3 files changed
tree: f22759e4993c3097938c03ee512f92ccbd336301
- bootstrap/
- bpfmt/
- bpmodify/
- deptools/
- gotestmain/
- gotestrunner/
- loadplugins/
- parser/
- pathtools/
- proptools/
- tests/
- .gitignore
- .travis.fix-fork.sh
- .travis.gofmt.sh
- .travis.install-ninja.sh
- .travis.yml
- blueprint.bash
- Blueprints
- bootstrap.bash
- build.ninja.in
- context.go
- context_test.go
- CONTRIBUTING.md
- doc.go
- fs.go
- LICENSE
- live_tracker.go
- mangle.go
- module_ctx.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
README.md
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.