Add section about platforms to rule deployment guide

[mboes]

Description of the feature request:

The Bazel rule deployment guide explains what to do about constraints and where they are expected to go. The guide should likewise cover where to put platform definitions.

Feature requests: what underlying problem are you trying to solve with this feature?

It is not clear where users should expect to find platform definitions. These should have a somewhat canonical and stable location, since they will be mentioned in the CLI --host_platform flag etc.

[gregestren]

• @katre FYI

[gregestren]

This is a fair question and I agree the guidance should be more precise.

I think the ultimate answer will still be kind of vague: different organizations can define platforms that match whatever their specific machine specs are, and we'd expect that to vary between orgs. And I think the guidance should be to show how to spec up your org's platforms as easily as possible.

But even that varies across orgs: Macs are fairly standardized for Apple builds, while C++ builds can built for any machine on the planet.

@katre I'm happy to clarify these things but do you know what the best source of wisdom currently is on this?

[katre]

In general, rules shouldn't create platforms: users and projects should create platforms that make sense for them, using constraints defined by rules (and by users and projects).

Specific examples would be Apple or Android device platforms: those rules define constraints useful for describing the devices (ios or android os constraints, device-specific hardware constraints, etc). But projects should then take those and define the the specific device platforms they need: this project is for Android phones, that project is for Apple watchOS apps.

Several rules currently define platforms (specifically rules_go defined several dozen as a convenience for users). I think this is ultimately the wrong direction, and isn't going to work cleanly when users are mixing different rule sets: when the Android rules are updated to use platforms: rules_go shouldn't need to be updated in order for users to write native Android device code in Go: the rules should work together with a platform written by the user to define "the platform my Go code will execute on, which has these Android-specific constraints and these generic constraints".