diff options
| author |  Carmi Grushko <carmi@google.com> | 2016-11-18 17:58:09 +0000 |
|---|---|---|
| committer |  Dmitry Lomov <dslomov@google.com> | 2016-11-21 19:36:33 +0000 |
| commit | babd485f80de515bcadd99bb645b519f26230b9a (patch) | |
| tree | 0f8f5fa8d8b4355b6c63a2d7e58e8c9ffb81521c /src/main/java/com/google/devtools/build/lib/rules/objc/IosDeviceRule.java | |
| parent | ccf96e331f970627a96d43b781ef1ad013a0e90a (diff) | |
Extra-actions originating in Aspects are reported even if the rule we attach to also registers extra-actions.
ExtraActionArtifactsProvider was using a set of ExtraArtifactSet, whose key was derived from the label of the owner of the extra-action.
Since actions registered by Aspects have the same label as those registered by the base rule, the former ones would disappear from the set.
An alternative to this CL would be to use an ArtifactOwner instead of a label as the key of the ExtraArtifactSet, but
1. BuildView only has access to ConfiguredTarget's, which lack the information to manipulate ArtifactOwner's; and
2. I don't see what ExtraArtifactSet gains us. In particular, ExtraArtifactSet.getLabel() is not used by anything outside of ExtraArtifactSet.
The only disadvantage of this CL is that filtering (--experimental_extra_action_filter) can be slower if targets register a massive number of actions.
Before this CL, we would match a single label per rule, while after this CL we match a single label per action.
--
MOS_MIGRATED_REVID=139591862
Diffstat (limited to 'src/main/java/com/google/devtools/build/lib/rules/objc/IosDeviceRule.java')
0 files changed, 0 insertions, 0 deletions