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
  1. bootstrap/
  2. bpfmt/
  3. bpmodify/
  4. deptools/
  5. gotestmain/
  6. gotestrunner/
  7. loadplugins/
  8. microfactory/
  9. parser/
  10. pathtools/
  11. proptools/
  12. tests/
  13. .gitignore
  14. .travis.fix-fork.sh
  15. .travis.gofmt.sh
  16. .travis.install-ninja.sh
  17. .travis.yml
  18. blueprint.bash
  19. blueprint_impl.bash
  20. Blueprints
  21. bootstrap.bash
  22. context.go
  23. context_test.go
  24. CONTRIBUTING.md
  25. doc.go
  26. glob.go
  27. glob_test.go
  28. LICENSE
  29. live_tracker.go
  30. mangle.go
  31. module_ctx.go
  32. name_interface.go
  33. ninja_defs.go
  34. ninja_strings.go
  35. ninja_strings_test.go
  36. ninja_writer.go
  37. ninja_writer_test.go
  38. package_ctx.go
  39. README.md
  40. scope.go
  41. singleton_ctx.go
  42. splice_modules_test.go
  43. unpack.go
  44. unpack_test.go
  45. visit_test.go
README.md

Blueprint Build System

Build Status

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.