| commit | 9577bbc922f96d3b3dfae8b51e5397aead0f7322 | [log] [tgz] |
|---|---|---|
| author | Ulya Trafimovich <skvadrik@google.com> | Thu Aug 27 11:20:23 2020 +0100 |
| committer | Ulya Trafimovich <skvadrik@google.com> | Thu Sep 17 11:43:15 2020 +0100 |
| tree | 14f951dae3a361bcb9a531e2d31e8bac1e573a17 | |
| parent | 4b3efdc5b875cc79058c069fffa38ca65d4eb0ab [diff] |
Return dependency modules from dependency-adding methods.
The motivaion for this change is to allow writing code that uses the
newly added dependency module in the same mutator pass, for example to
add more dependencies. Like this:
for _, m := range ctx.AddVariationDependencies(nil, tag, deps...) {
if someModuleProperty(m); ok {
ctx.AddVariationDependencies(nil, tag, otherDep)
}
}
Note that there is no guarantee that the returned module has already
been processed by the current mutator.
The patch does not add runtime overhead on findng dependency modules,
as this has already been done previously.
Test: go test
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.