// 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.rules; import com.google.devtools.build.lib.actions.ActionAnalysisMetadata; import com.google.devtools.build.lib.analysis.ConfiguredTarget; import com.google.devtools.build.lib.analysis.RuleContext; import com.google.devtools.build.lib.packages.RuleClass; /** * 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 target (e.g. //src:bazel
) and
* a {@link com.google.devtools.build.lib.analysis.config.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: *