Are platforms and execution platforms different?

[katre]

Background

Currently, Bazel has three ways platforms can be used:

1. The host platform (where Bazel executes, one per invocation)
2. The target platform (where built artifacts will be used, one per configuration)
3. A number of execution platforms (where build actions execute, one per exec group)

These are all declared using the same rule, platform.

However, there are a number of attributes on the platform rule that only make sense for execution platforms:

1. platforms.exec_properties
   1. A map of keys and values. These can be used with exec groups to set exec group-specific properties, and for remote execution can be used to configure the remote worker for an action.
2. platforms.remote_execution_proeprties
   1. This is deprecated, but serves the same purpose as exec_properties for remote actions.

There are also some future possible additions and/or changes:

1. In Execution Platforms vs Strategies, discussed adding further attributes to control which execution strategies are compatible with specific execution platforms.
2. A future change to --experimental_platform_in_output_dir could be to use properties on the target platform to get the name for the output dir, instead of using --experimental_override_name_platform_in_output_dir.
3. It's actually entirely possible for native rules to read the exec_properties of the target platform and use that to make decisions. While this hasn't happened in Bazel, Google's internal Blaze uses this in a few places.

The actual question

Okay, I even surprised myself with all that, but this has been brewing for some time. Now for my actual questions for users:

Is an exec platform different enough to use a different rule?

Based on the above, target platforms have a very few attributes: a name, a parent, constraint values, and maybe a generic "properties" grab-bag for rules and Bazel to use. (Or maybe we force Bazel, at least, to use actual attributes for things like output path segments).

Execution platforms, on the other hand, also have a name, a parent, and constraint values, but also have execution properties (which can be used for execution strategies including remote), and may have further things added in the future.

Is it worth splitting these up? An execution platform would need the following semantics that a platform doesn't have:

1. An execution platform can inherit from a platform
   1. Can a non-exec platform inherit from an exec platform?
2. An execution platform can be used as a target platform only after the execution transition
   1. What happens to the host platform? By default, that's the target and the exec platform. Do we just special-case it?
3. We'd need an extended ExecPlatformInfo provider that is similar to the existing PlatformInfo, but that's just a Simple Matter of Programming.

I'd like to know what actual users think, and whether this is worth advancing. (I have an ulterior motive: I want to add a new feature to execution platforms and so this is the right time to decide whether to split them out. Proposal to come after this question is resolved.)

[pettermahlen]

The document link to Execution Platforms vs Strategies above is broken for me. This one works.

[katre]

Thanks, fixed it!

[cgrindel]

Can a non-exec platform inherit from an exec platform?

Please, no. This would blur the semantic difference.

What happens to the host platform? By default, that's the target and the exec platform. Do we just special-case it?

Or, is that we create a default exec platform that inherits from the host platform?

Personally, I like separating the exec platform attributes from the non-exec platform rule. It makes it easier to understand. However, I am ambivalent about whether there is a strict distinction between an exec and a non-exec platform. I am trying to think of the foot-gun scenarios. 🤔

[gregestren]

Can you clarify the differences you're thinking of besides exec_properties?

I'm curious to know what --extra_execution_platforms or register_execution_platforms settings people set and how often those re-use target platform definitions.

[katre]

I have a pending proposal to add a settings attribute (or exec_settings) to paltforms, analagous to toolchain.target_settings: a list of config_setting targets to check to decide whether the execution platform should be valid. The intended use case is for incremental rollouts of special execution platforms.

I want to know if this should be on platform or a new execution_platform rule.