Support multiple platform parents

[ismell]

Description of the feature request:

According to the platform inheritance document, a platform can have an array of parents, but only 1 parent is currently supported. This feature request is about adding support for multiple parents. This is not a feature we need any time soon, just filing the bug so we don't lose track of the work required.

What underlying problem are you trying to solve with this feature?

ChromeOS uses portage overlays for defining config. Each overlay can have multiple parents.

An example of the guybrush-private overlay:

masters = portage-stable chromiumos eclass-overlay chipset-cezanne-private cheets-private guybrush

This means that the default values are constructed by traversing each parent and applying any overrides. While most of this can be flattened into a single hierarchy:

i.e.,

portage-stable -> chromiumos -> eclass-overlay -> chipset-cezanne -> chipset-cezanne-private -> guybrush ->guybrush-private

We run into a problem with cheets-private. cheers-private contains the config values for enabling the Android Runtime Container on ChromeOS. So it's more of a feature that we can pull in when applicable. If I was modeling this with platforms, I would ideally have guybrush-private have two parents, guybrush, and cheets-private.

One thing I'm not sure how to handle is the private and public inheritance. public builds don't have access to the -private overlays. Modeling the public chain is simple:

guybrush -> chipset-cezanne -> eclass-overlay -> chromiumos -> portage-stable

The private graph gets a little complicated though because we end up with a diamond on chipset-cezanne.

guybrush-private
    -> cheets-private
    -> guybrush -> chipset-cezanne
    -> chipset-cezanne-private -> chipset-cezanne

In theory we could make chipset-cezanne-private not depend on chipset-cezanne, but I don't think it hurts. I think the algorithm would need to treat the first parents listed as low priority and the later parents with higher priority when computing the value.

Which operating system are you running Bazel on?

No response

What is the output of bazel info release?

No response

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

[katre]

This is being considered as future work, for now I'm putting it on our backlog.

[tpudlik]

A couple places this could have perhaps been useful in the embedded world:

1. https://github.com/bazelembedded/bazel-embedded/blob/master/platforms/BUILD defines a bunch of platforms that collect constraint_values it uses for toolchain resolution. But if you use any of these in your project, you've "eaten up" your platform inheritance slot. If you depend on any other project that defines "base" platforms (or want to define them in your own), you're toast. (Perhaps the answer here is that providing "base" platforms is an antipattern, and libraries should just provide lists of constraint_values in .bzl files. But how to handle overrides then?) @silvergasp FYI.
2. "Bazel Constraints for RISC-V" suggested representing well-known CPUs as base platforms containing the appropriate ISA extensions. That would have been neat, but would also "eat up" the user's base platform slot, and so was tentatively rejected.

I don't think either of these proposed use cases is extremely compelling, but noting them here for the record.