| tag | aafc486bf296e6416a958e059d4cfbb3ae183c73 | |
|---|---|---|
| tagger | The Android Open Source Project <initial-contribution@android.com> | Mon May 04 12:27:45 2020 -0700 |
| object | ba1ea7583953186a1a5519c0cd1087e403ad516f |
Android 10.0.0 release 34
| commit | ba1ea7583953186a1a5519c0cd1087e403ad516f | [log] [tgz] |
|---|---|---|
| author | Jiyong Park <jiyong@google.com> | Mon Jul 29 19:59:15 2019 +0900 |
| committer | Jiyong Park <jiyong@google.com> | Fri Aug 16 13:45:44 2019 +0900 |
| tree | 7e45239ca47a3572cfd7f120421b736d886555e6 | |
| parent | 12bcfa5e9b104e2fceaf6a5207af0f718b01d96a [diff] |
Add SetDefaultDependencyVariation
SetDefaultDependencyVariation sets the variation name that will be used
when a dangling dependency is found while a module is being split. A
dangling dependency can occur if a module is split to a variant that one
of its dependencies is not split into. When the default variation is not
set, such dangling dependency is a hard error. But with the new
function, the default variation can be set and subsequent calls to
CreateVariations and its variations on the same context uses the default
variation when necessary.
(If even the default variation does not exist for the dependent module,
it is an hard error)
Note that this is different from calling SetDependencyVariation("foo")
followed by CreateVariations("foo", "bar"). In that case, regardless of
whether a dependency of the current module has the variant 'bar' or not,
only the 'foo' variant is chosen.
With SetDefaultDependencyVariation("foo") followed by
CreateVariations("foo", "bar"), 'foo' variant is used only when the
'bar' variant of the current module depends on a module that does not
have 'bar' variant.
Bug: 138103882
Test: m
Merged-In: I2c79c3c9e0437fd785b06ca20f43da2963d50b68
(cherry picked from commit 1e2e56dc624bd93845288d803be588c597f0bd6f)
Change-Id: I4520ca87487994de024fdbacda3bef6636225f0d
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.