|author||Colin Cross <email@example.com>||Mon Apr 11 15:47:28 2016 -0700|
|committer||Colin Cross <firstname.lastname@example.org>||Tue Apr 12 14:52:46 2016 -0700|
Add support for dependency tags Primary builder logic is becoming complicated due to the two pass nature of mutators that add dependencies and GenerateBuildActions that handle the dependencies. The reason why the dependency was added is lost by the time GenerateBuildActions is called, resulting in build logic that has to recreate all the dependencies and try to match them up to the modules returned by VisitDirectDeps. Change the API of AddDependency to take a DependencyTag interface, which is satisifed by anything that embeds BaseDependencyTag. Mutators and GenerateBuildActions that call VisitDirectDeps can pass each Module to ctx.OtherModuleDependencyTag to retreive the DependencyTag that was passed when adding the dependency. Change-Id: I0814dcd26d1670302d340b77e8dc8704ed7b60bf
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.