Fix bugs related to local vs. inherited variables

The Go race detector found a race condition in the parser, which
 highlighted a few related bugs. A variable could be defined but
not referenced in a Blueprints file, then appended to in multiple
subdirs= Blueprints files.  The race detector caught the multiple
writes to assignment.Referenced from the parsers for the subdirs
Blueprints files, but multiple appends would be much more serious.

To fix this, keep local and inherited variables separate in the
Scope object and export that info to the parser.  Disallow
appending to non-local variables, which was already the intended
behavior.  Only update the referenced boolean for local variables.
Together, this should prevent all writes to Assignment objects
from parsers other than the one that created them.

Also improves the error handling code and some error messages.

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