Skip to main content
Global methods available in all .bzl files.

Members

analysis_test_transition

Creates a configuration transition to be applied on an analysis-test rule’s dependencies. This transition may only be applied on attributes of rules with analysis_test = True. Such rules are restricted in capabilities (for example, the size of their dependency tree is limited), so transitions created using this function are limited in potential scope as compared to transitions created using transition(). This function is primarily designed to facilitate the Analysis Test Framework core library. See its documentation (or its implementation) for best practices.

Parameters

aspect

Creates a new aspect. The result of this function must be stored in a global value. Please see the introduction to Aspects for more details.

Parameters

configuration_field

References a late-bound default value for an attribute of type label. A value is ‘late-bound’ if it requires the configuration to be built before determining the value. Any attribute using this as a value must be private. Example usage: Defining a rule attribute:
Accessing in rule implementation:

Parameters

depset

Creates a depset. The direct parameter is a list of direct elements of the depset, and transitive parameter is a list of depsets whose elements become indirect elements of the created depset. The order in which elements are returned when the depset is converted to a list is specified by the order parameter. See the Depsets overview for more information. All elements (direct and indirect) of a depset must be of the same type, as obtained by the expression type(x). Because a hash-based set is used to eliminate duplicates during iteration, all elements of a depset should be hashable. However, this invariant is not currently checked consistently in all constructors. Use the —incompatible_always_check_depset_elements flag to enable consistent checking; this will be the default behavior in future releases; see Issue 10313. In addition, elements must currently be immutable, though this restriction will be relaxed in future. The order of the created depset should be compatible with the order of its transitive depsets. "default" order is compatible with any other order, all other orders are only compatible with themselves.

Parameters

exec_group

Creates an execution group which can be used to create actions for a specific execution platform during rule implementation.

Parameters

exec_transition

A specialized version of transition() used to define the exec transition. See its documentation (or its implementation) for best practices. Only usable from the Bazel builtins.

Parameters

macro

Defines a symbolic macro, which may be called in BUILD files or macros (legacy or symbolic) to define targets – possibly multiple ones. The value returned by macro(...) must be assigned to a global variable in a .bzl file; the name of the global variable will be the macro symbol’s name. See Macros for a comprehensive guide on how to use symbolic macros.

Parameters

materializer_rule

Creates a new materializer rule, which can be called from a BUILD file or a macro to create materializer targets. Materializer targets are used to dynamically select dependencies at analysis time. Targets which depend on a materializer target will see the materialized dependencies, rather than the materializer target itself.

Parameters

module_extension

Creates a new module extension. Store it in a global value, so that it can be exported and used in a MODULE.bazel file with use_extension.

Parameters

provider

Defines a provider symbol. The resulting value of this function must be stored in a global value to be usable in a rule or aspect implementation. Providers can be instantiated by calling the resulting value as a function, or used directly as an index key for retrieving an instance of that provider from a target. Example:
See Rules (Providers) for a comprehensive guide on how to use providers. Returns a Provider callable value if init is not specified. If init is specified, returns a tuple of 2 elements: a Provider callable value and a raw constructor callable value. See Rules (Custom initialization of custom providers) and the discussion of the init parameter below for details.

Parameters

repository_rule

Creates a new repository rule. Store it in a global value, so that it can be loaded and called from a module_extension() implementation function, or used by use_repo_rule().

Parameters

rule

Creates a new rule, which can be called from a BUILD file or a macro to create targets. Rules must be assigned to global variables in a .bzl file; the name of the global variable is the rule’s name. Test rules are required to have a name ending in _test, while all other rules must not have this suffix. (This restriction applies only to rules, not to their targets.)

Parameters

select

select() is the helper function that makes a rule attribute configurable. See build encyclopedia for details.

Parameters

subrule

Constructs a new instance of a subrule. The result of this function must be stored in a global variable before it can be used.

Parameters

tag_class

Creates a new tag_class object, which defines an attribute schema for a class of tags, which are data objects usable by a module extension.

Parameters

visibility

Sets the load visibility of the .bzl module currently being initialized. The load visibility of a module governs whether or not other BUILD and .bzl files may load it. (This is distinct from the target visibility of the underlying .bzl source file, which governs whether the file may appear as a dependency of other targets.) Load visibility works at the level of packages: To load a module the file doing the loading must live in a package that has been granted visibility to the module. A module can always be loaded within its own package, regardless of its visibility. visibility() may only be called once per .bzl file, and only at the top level, not inside a function. The preferred style is to put this call immediately below the load() statements and any brief logic needed to determine the argument. If the flag --check_bzl_visibility is set to false, load visibility violations will emit warnings but not fail the build.

Parameters