// Copyright 2015 The Bazel Authors. All rights reserved. // // Licensed under the Apache License, Version 2.0 (the "License"); // you may not use this file except in compliance with the License. // You may obtain a copy of the License at // // http://www.apache.org/licenses/LICENSE-2.0 // // Unless required by applicable law or agreed to in writing, software // distributed under the License is distributed on an "AS IS" BASIS, // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. // See the License for the specific language governing permissions and // limitations under the License. package com.google.devtools.build.lib.packages; /** * A class of aspects. * *
An aspect allows a rule to create actions in its dependencies, without their knowledge. * It can be viewed as the ability to attach shadow targets to transitive dependencies or a way * to run visitations of certain parts of the transitive closure of a rule in such a way that can * be cached (even partially) and reused between different configured targets requiring the same * aspect. Some examples where aspects are useful: * *
proto_library
and the messages it depends
* onWhen a configured target requests that an aspect be attached to one of its dependencies, * the {@link com.google.devtools.build.lib.analysis.TransitiveInfoProvider}s generated by that * aspects are merged with those of the actual dependency, that is, * {@link com.google.devtools.build.lib.analysis.RuleContext#getPrerequisite( * String, com.google.devtools.build.lib.analysis.RuleConfiguredTarget.Mode)} will * contain the transitive info providers produced both by the dependency and the aspects that are * attached to it. * *
Configured targets can specify which aspects should be attached to some of their dependencies * by specifying this in their {@link com.google.devtools.build.lib.analysis.RuleDefinition}: each * attribute can have a list of aspects to be applied to the rules in that attribute and each * aspect can specify which {@link com.google.devtools.build.lib.analysis.TransitiveInfoProvider}s * it needs on a rule so that it can do meaningful work (for example, dexing only makes sense for * configured targets that produce Java code). * *
Aspects can be defined natively, in Java ({@link NativeAspectClass}) * or in Skylark ({@link SkylarkAspectClass}). * * Bazel propagates aspects through a multistage process. The general pipeline is as follows: * *
* {@link AspectClass} * | * V * {@code AspectDescriptor} <- {@link AspectParameters} * \ * V * {@link Aspect} <- {@link AspectDefinition} (might require loading Skylark files) * | * V * {@code ConfiguredAspect} <- {@code ConfiguredTarget} ** *