Platform Rules

Rules

constraint_setting
constraint_value
platform
toolchain

constraint_setting

constraint_setting(name, default_constraint_value, deprecation, distribs, exec_compatible_with, features, licenses, tags, testonly, visibility)

This rule is used to introduce a new constraint type for which a platform may specify a value. For instance, you might define a constraint_setting named "glibc_version" to represent the capability for platforms to have different versions of the glibc library installed. See the Platforms page for more details.

Each constraint_setting has an extensible set of associated constraint_values. Usually these are defined in the same package, but sometimes a different package will introduce new values for an existing setting. For instance, the predefined setting @platforms//cpu:cpu can be extended with a custom value in order to define a platform targeting an obscure cpu architecture.

Arguments

Attributes

name

Name; required

A unique name for this target.

default_constraint_value

Name; optional

The label of the default value for this setting, to be used if no value is given. If this attribute is present, the constraint_value it points to must be defined in the same package as this constraint_setting.

If a constraint setting has a default value, then whenever a platform does not include any constraint value for that setting, it is the same as if the platform had specified the default value. Otherwise, if there is no default value, the constraint setting is considered to be unspecified by that platform. In that case, the platform would not match against any constraint list (such as for a config_setting) that requires a particular value for that setting.

constraint_value

constraint_value(name, constraint_setting, deprecation, distribs, exec_compatible_with, features, licenses, tags, testonly, visibility)

This rule introduces a new value for a given constraint type. See the Platforms page for more details.

Example

The following creates a new possible value for the predefined constraint_value representing cpu architecture.

constraint_value(
    name = "mips",
    constraint_setting = "@platforms//cpu:cpu",
)

Platforms can then declare that they have the mips architecture as an alternative to x86_64, arm, and so on.

Arguments

Attributes

name

Name; required

A unique name for this target.

constraint_setting

Label; required

The constraint_setting for which this constraint_value is a possible choice.

platform

platform(name, constraint_values, deprecation, distribs, exec_compatible_with, features, licenses, parents, remote_execution_properties, tags, testonly, visibility)

This rule defines a new platform -- a named collection of constraint choices (such as cpu architecture or compiler version) describing an environment in which part of the build may run. See the Platforms page for more details.

Example

This defines a platform that describes any environment running Linux on ARM.

platform(
    name = "linux_arm",
    constraint_values = [
        "@platforms//os:linux",
        "@platforms//cpu:arm",
    ],
)

Platform Inheritance

Platforms may use the "parents" attribute to specify another platform that they will inherit constraint values from. Although the "parents" attribute takes a list, no more than a single value is currently supported, and specifying multiple parents is an error.

When checking for the value of a constraint setting in a platform, first the values directly set (via the "constraint_values" attribute) are checked, and then the constraint values on the parent. This continues recursively up the chain of parent platforms. In this manner, any values set directly on a platform will override the values set on the parent.

Platforms can also inherit the "remote_execution_properties" attribute from the parent platform. The logic for setting the "remote_execution_platform" is as follows when there is a parent platform:

If "remote_execution_property" is not set on the child platform, the parent's "remote_execution_properties" will be used.
If "remote_execution_property" is set on the child platform, and contains the literal string "{PARENT_REMOTE_EXECUTION_PROPERTIES}", that macro will be replaced with the contents of the parent's "remote_execution_property" attribute.
If "remote_execution_property" is set on the child platform, and does not contain the macro, the child's "remote_execution_property" will be used unchanged.

Example

platform(
    name = "parent",
    constraint_values = [
        "@platforms//os:linux",
        "@platforms//cpu:arm",
    ],
    remote_execution_properties = """
      parent properties
    """,
)
platform(
    name = "child_a",
    parents = [":parent"],
    constraint_values = [
        "@platforms//cpu:x86_64",
    ],
    remote_execution_properties = """
      child a properties
    """,
)
platform(
    name = "child_b",
    parents = [":parent"],
    remote_execution_properties = """
      child b properties
      {PARENT_REMOTE_EXECUTION_PROPERTIES}
      more child b properties
    """,
)

In these examples, the child platforms have the following properties:

"child_a" has the constraint values "@platforms//os:linux" (inherited from the parent) and "@platforms//cpu:x86_64" (set directly on the platform). It has the "remote_execution_properties" set to "child a properties"
"child_b" inherits all constraint values from the parent, and doesn't set any of its own. It has the "remote_execution_properties" set to:
```
child b properties
parent properties
more child b properties
```

Arguments

Attributes
`name`	`Name; required` A unique name for this target.
`constraint_values`	`List of labels; optional` The combination of constraint choices that this platform comprises. In order for a platform to apply to a given environment, the environment must have at least the values in this list. Each `constraint_value` in this list must be for a different `constraint_setting`. For example, you cannot define a platform that requires the cpu architecture to be both `@platforms//cpu:x86_64` and `@bazel_tools//platforms:arm`.
`parents`	`List of labels; optional` The label of a `platform` target that this platform should inherit from. Although the attribute takes a list, there should be no more than one platform present. Any constraint_settings not set directly on this platform will be found in the parent platform. See the section on Platform Inheritance for details.
`remote_execution_properties`	`String; optional` A string used to configure a remote execution platform. Actual builds make no attempt to interpret this, it is treated as opaque data that can be used by a specific SpawnRunner. This can include data from the parent platform's "remote_execution_properties" attribute, by using the macro "{PARENT_REMOTE_EXECUTION_PROPERTIES}". See the section on Platform Inheritance for details.

toolchain

toolchain(name, deprecation, distribs, exec_compatible_with, features, licenses, tags, target_compatible_with, testonly, toolchain, toolchain_type, visibility)

This rule declares a specific toolchain's type and constraints so that it can be selected during toolchain resolution. See the Toolchains page for more details.

Arguments

Attributes
`name`	`Name; required` A unique name for this target.
`exec_compatible_with`	`List of labels; optional; nonconfigurable` A list of `constraint_value`s that must be satisfied by an execution platform in order for this toolchain to be selected for a target building on that platform.
`target_compatible_with`	`List of labels; optional; nonconfigurable` A list of `constraint_value`s that must be satisfied by the target platform in order for this toolchain to be selected for a target building for that platform.
`toolchain`	`Name; required; nonconfigurable` The target representing the actual tool or tool suite that is made available when this toolchain is selected.
`toolchain_type`	`Label; required; nonconfigurable` The label of a `toolchain_type` target that represents the role that this toolchain serves.