| commit | a1e6eeeb44d954a9a6413ea2d956a97d13c31f68 | [log] [tgz] |
|---|---|---|
| author | Dan Willemsen <dwillemsen@google.com> | Fri Mar 02 14:54:17 2018 -0800 |
| committer | Dan Willemsen <dwillemsen@google.com> | Fri Mar 02 15:29:35 2018 -0800 |
| tree | ed92fcbe0668abd8d67becdd2b11663ff9ef3f37 | |
| parent | 774db4a8aa120621912768d51d009359bd8fa8f5 [diff] |
Try to make GOROOT relative in Go 1.10 In Go 1.10, runtime.GOROOT() will attempt to find the current location of the go binaries, instead of using the GOROOT_FINAL that was baked into the binaries. This means that GOROOT() will usually return an absolute path. We avoid putting absolute paths into the ninja file, since any change to the paths would then cause all of the actions including it to rebuild. Since we've got a decent number of build tools in Android using Go now, this causes us to rebuild a decent portion of the tree. Instead of passing the GOROOT around manually in a side channel, just let the Go 1.10 detection do its thing, and always try to turn the result into a relative path.
1 file changed
tree: ed92fcbe0668abd8d67becdd2b11663ff9ef3f37
- 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.