Avoid exiting with errors in bpglob

bpglob is only used as a helper to check if the primary builder
needs to rerun due to the results of a glob changing.  A recent
change to glob support in pathtools made a glob format that was
accidentally previously accepted into an error.  If the bad
syntax was used in the most recent primary builder run, and
then an incremental build is performed after picking up the
change that made the syntax invalid, then bpglob will attempt
to rerun before the primary builder, see the now-invalid syntax,
and fail.  This will prevent the primary builder from rerunning,
which would have updated the bpglob rule with a corrected glob
syntax (or failed in the primary builder if the Blueprints file
still had the invalid glob syntax).

Avoid exiting with an error in bpglob.  Instead, write the
error to the output file along with a timestamp so that it is
always dirty, forcing the primary builder to rerun.

Bug: 129411151
Test: m nothing
Change-Id: Ib680570c33662f3c0f1f72425d60a963ed841ba6
1 file changed
tree: 1647d4be24954f829c3da9c842c363f62c4aef69
  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. go.mod
  29. LICENSE
  30. live_tracker.go
  31. mangle.go
  32. module_ctx.go
  33. name_interface.go
  34. ninja_defs.go
  35. ninja_strings.go
  36. ninja_strings_test.go
  37. ninja_writer.go
  38. ninja_writer_test.go
  39. package_ctx.go
  40. README.md
  41. scope.go
  42. singleton_ctx.go
  43. splice_modules_test.go
  44. unpack.go
  45. unpack_test.go
  46. 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.