commit | 20c343b89ee729577427cad55db6875bb0307415 | [log] [tgz] |
---|---|---|
author | Dan Willemsen <dwillemsen@google.com> | Fri Mar 02 15:03:24 2018 -0800 |
committer | Dan Willemsen <dwillemsen@google.com> | Fri Mar 02 15:32:22 2018 -0800 |
tree | de7aa9dd354d1d4508b4b582eef7c883b8fcddc7 | |
parent | 774db4a8aa120621912768d51d009359bd8fa8f5 [diff] |
Cap the number of cpus for Go compiles When passing "-c" to the Go compiler, any time this value changes, we'd force all of the Go compiles to rebuild. This could trigger a substantial portion of the tree to rebuild (anything that transitive depends on a Go helper tool). We're running into issues when moving output directories between multiple GCE machines with different core counts, but are otherwise identical. This could also hit users moving/mounting disks between machines, though changes to other host tools can make an impact too. On my 48-core machine, I get a ~15% benefit from going from -c 1 to -c 48, but also ~12% benefit from going from -c 1 to -c 8. So this will still let us scale somewhat, but prevent rebuilds when transitioning between machines that are more likely building Android.
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.