| commit | efd2de734d972764764be5ca950882b40eb182e4 | [log] [tgz] |
|---|---|---|
| author | Dan Willemsen <dwillemsen@google.com> | Wed Jul 22 17:06:06 2015 -0700 |
| committer | Dan Willemsen <dwillemsen@google.com> | Wed Jul 29 17:14:00 2015 -0700 |
| tree | ad6f8364ce9baa1e68e691abf11fec5a68f69b8a | |
| parent | 91a657e219aa226df400ac30c0982820912051fa [diff] |
Use three stage builds This splits the current bootstrap stage into two stages: A bootstrap stage, which like today, a reference is checked into the tree. It just builds the "core" blueprint binaries -- minibp, gotestmain, and choosestage. Just enough to build the next stage's ninja file. A primary builder stage. This builds the primary builder, the main ninja file, and any other bootstrap binaries (bpfmt, etc). The main advantage here is that the checked in file really only contains references to blueprint -- not the primary builder. This will allow us to make the primary builder more dynamic, by loading more module types that may or may not exist in all trees. It's even possible to reuse the build.ninja.in in the blueprint repo directly now. We don't currently do that, since we still want to turn on tests. Change-Id: I18683891ed7348b0d7af93084e3a68a04fbd5dbc
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.