diff options
author | 2017-07-28 15:58:02 +0200 | |
---|---|---|
committer | 2017-07-31 16:32:05 +0200 | |
commit | c8331a7af24eca1ab8b8997589f1ea07ee5220e5 (patch) | |
tree | 20fc7865b50a692a19c85febe1391cd266d79a49 /src/test/java/com/google/devtools/build/lib/util/PathFragmentFilterTest.java | |
parent | 8177f3f1d1ce1947a452fc30d67f2370a3cce598 (diff) |
Use dynamically configured resource filtering
Actually hook up the resource filtering configuration transitions to
AndroidConfiguration's topLevelConfigurationHook.
Dynamic configuration is inefficient when multiple configurations are used.
Multiple configurations result in splitting the build graph and duplicating
work.
To avoid using multiple configurations as much as possible, dynamically
configured resource filtering will only be applied for top-level android_binary
targets. When android_binary targets are included as dependencies, it's very
likely that multiple binaries with many shared dependencies but different
configurations would be used. Only applying dynamic filtering to top-level
binaries removes this concern.
It is still possible to build multiple top-level binary targets with different
configurations at once. Previous versions of this code considered not using
dynamic configuration in that case as well, but that raised some unanswered
questions about whether Bazel's invariants should allow modifying one target's
configuration based solely on targets that happen to be building in parallel.
As a result, that optimization is not included for now; we assume that
developers manually building multiple similar binaries at once is relatively
rare (plus, dynamically configured resource filtering in general is not turned
on by default and will not be turned on by default until we're confident the
benefits outweigh the costs).
RELNOTES: none
PiperOrigin-RevId: 163464415
Diffstat (limited to 'src/test/java/com/google/devtools/build/lib/util/PathFragmentFilterTest.java')
0 files changed, 0 insertions, 0 deletions