Fix misparsed $ after variable name

If a $ sign occurs after a variable name, the ninja string parser
fails to check if it is a $$ or a ${.  Go to the
parseDollarStartState instead of the parseDollarState.

Since it is not yet known if the $ is the beginning of a new
variable (${ or $<alphanumeric>) or a string ($$), an empty string
separator cannot be added to the ninjaString strings list.  Instead,
add functions to push strings or variables onto the ninjaString,
and automatically add the blank separator if two variables are
pushed in a row.

Change-Id: Ia1cae6259b1d7e4f633f61b9eadb2a2028bbd5f0
2 files changed
tree: e3a5460033049ef6249537bc64ec22fecaf200e6
  1. bootstrap/
  2. bpfmt/
  3. bpmodify/
  4. deptools/
  5. parser/
  6. pathtools/
  7. proptools/
  8. .travis.yml
  9. Blueprints
  10. bootstrap.bash
  11. build.ninja.in
  12. context.go
  13. context_test.go
  14. CONTRIBUTING.md
  15. doc.go
  16. LICENSE
  17. live_tracker.go
  18. mangle.go
  19. module_ctx.go
  20. ninja_defs.go
  21. ninja_strings.go
  22. ninja_strings_test.go
  23. ninja_writer.go
  24. ninja_writer_test.go
  25. package_ctx.go
  26. README.md
  27. scope.go
  28. singleton_ctx.go
  29. splice_modules_test.go
  30. unpack.go
  31. 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.