// Copyright 2014 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.analysis; import com.google.devtools.build.lib.actions.ActionAnalysisMetadata; import com.google.devtools.build.lib.actions.MutableActionGraph.ActionConflictException; import com.google.devtools.build.lib.analysis.config.BuildConfiguration; import com.google.devtools.build.lib.cmdline.Label; import com.google.devtools.build.lib.packages.RuleClass; import com.google.devtools.build.lib.skyframe.BuildConfigurationValue; /** * A shortcut class to the appropriate specialization of {@code RuleClass.ConfiguredTargetFactory}. * *
Here follows an overview of how loading and analysis works in Bazel: * *
Actions (i.e. commands that are run during the build) are created by configured targets (see
* {@link ConfiguredTarget}), which are a pair of a {@link Label} (e.g. //src:bazel
)
* and a {@link BuildConfigurationValue#Key}, which is a key for a {@link BuildConfiguration}, which
* is a blob of data that contains extra information about how the target should be built (for
* example, for which platform or with which C++ preprocessor definitions). Accordingly, a target
* can give rise to multiple configured targets, for example, if it needs to be built both for the
* host and the target configuration.
*
*
The process of creating the appropriate {@link com.google.devtools.build.lib.actions.Action}s * for a configured target is called "analysis". The analysis of a configured target is composed of * the following steps (which process is orchestrated by {@link * com.google.devtools.build.lib.skyframe.ConfiguredTargetFunction}): * *
*
* cc_binary
). Rule classes can be defined either in Skylark using the rule()
*
function or in Java code by implementing {@link
* com.google.devtools.build.lib.analysis.RuleDefinition}.
*
* During the analysis of a configured target, the following pieces of data are available: * *
Analysis of non-rule configured targets is special-cased and is not covered here. * *
The analysis of a rule itself is done by implementations {@link * RuleConfiguredTargetFactory} (there should be one for each rule class). The data above is * available using the {@link RuleContext} argument passed into its create() method. It should * result in three things: * *
Configured targets are currently allowed to create artifacts at any exec path. It would be * better if they could be constrained to a subtree based on the label of the configured target, * but this is currently not feasible because multiple rules violate this constraint and the * output format is part of its interface. * *
In principle, multiple configured targets should not create actions with conflicting * outputs. There are still a few exceptions to this rule that are slated to be eventually * removed, we have provisions to handle this case (Action instances that share at least one * output file are required to be exactly the same), but this does put some pressure on the * design and we are eventually planning to eliminate this option. * *
These restrictions together make it possible to: * *