Add SingletonContext.Eval to evaluate ninja strings

Our use case is to write out some configuration variables to give to our
legacy build system. But in order to do that, we either need to keep a
Go copy of all of the configuration, and still have all the calls to
convert them to ninja variables, or evaluate our ninja variables.

Change-Id: If9dda305ed41bc8aabe57dd750a74d8b9af1d1a4
2 files changed
tree: c38180b8b81d77b44a37cce16b4f2dd2a89f48da
  1. .gitignore
  2. .travis.fix-fork.sh
  3. .travis.install-ninja.sh
  4. .travis.yml
  5. Blueprints
  6. CONTRIBUTING.md
  7. LICENSE
  8. README.md
  9. blueprint.bash
  10. bootstrap.bash
  11. bootstrap/
  12. bpfmt/
  13. bpmodify/
  14. build.ninja.in
  15. choosestage/
  16. context.go
  17. context_test.go
  18. context_test_Blueprints
  19. deptools/
  20. doc.go
  21. gotestmain/
  22. gotestrunner/
  23. live_tracker.go
  24. loadplugins/
  25. mangle.go
  26. module_ctx.go
  27. ninja_defs.go
  28. ninja_strings.go
  29. ninja_strings_test.go
  30. ninja_writer.go
  31. ninja_writer_test.go
  32. package_ctx.go
  33. parser/
  34. pathtools/
  35. proptools/
  36. scope.go
  37. singleton_ctx.go
  38. splice_modules_test.go
  39. tests/
  40. unpack.go
  41. unpack_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.