| 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.
1 file changed
tree: de7aa9dd354d1d4508b4b582eef7c883b8fcddc7
- 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
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.