Clone all modules between mutators and GenerateBuildActions

A common pattern in mutators is to set a property on a module to be used
later in GenerateBuildActions.  A common anti-pattern is to set a member
variable instead of a property.  Setting member variables will appear to
work until a mutator calls CreateVariations after the member variable is
set.  The first variant will have the member variables, but any other
variants will have zero values for all member variables.

To catch this common case early, replace all modules with clones after
running all the mutators but before GenerateBuildActions.

This catches the anti-pattern used in bootstrap, replace the buildStage
member variable with a property.

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