| commit | dac90d33ca2d09db6fe521b9a509b0a239a5d9e3 | [log] [tgz] |
|---|---|---|
| author | Dan Willemsen <dwillemsen@google.com> | Thu Oct 25 22:02:10 2018 -0700 |
| committer | Dan Willemsen <dwillemsen@google.com> | Fri Oct 26 09:57:24 2018 -0700 |
| tree | 17d0d06270afcb6fd210f85003e574b6674c84f6 | |
| parent | 19099e68bba4afab0f54e489b9730b3f50041ffb [diff] |
Add --empty-ninja-file for test usecases In cases that we want to run blueprint-based builds in many configurations to verify all of the logic works without errors, but don't care about running the final ninja file, writing it out only wastes time and disk space. So add a --empty-ninja-file option that writes out an empty ninja file instead. Our specific use case (Soong's build_test / multiproduct_kati) runs Soong several hundred times for different configurations, and the ninja files are around 1GB, which leads to several hundred gigabytes of disk writes (and persistent use during incremental generation). Change-Id: I0198dfb2f744ce22284c05d5214dac2ab5dc9700
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.