Migrate config_settings from core Bazel to platforms

[katre]

There are a number of widely used config_setting targets in @bazel_tools//src/conditions, that should probably actually be in the @platforms repository.

We should investigate migrating these to simplify the setup.

[cpsauer]

Chiming in after finding myself doubly redefining a bunch of {OS} x {CPU} combinations as config_setting()s and platform()s in my own projects...and seeing others do the same.

It definitely seems to me like it'd be great to have the common combinations officially in @platforms rather than having everyone (Bazel included) roll their own. Could be either the full cartesian product (yay list comprehensions!) or the subset that exist in the wild as physical machines. (Doubt the unused ones would hurt people, though.)

Some side notes:

• It's pretty sweet to be able to select on constraint_value()s, eliminating this problem for single values. Thank you for that!
• I've read the reasoning behind not letting people select on platforms (i.e. encouraging people to not write too narrow of selects()s...) but I would really like to put in a pitch for reversing in the context of the this issue. It seems like an avoidable bummer to duplicately define them and then have people be confused about which to use--especially if they're defined in an official place.)
  Edit: Additional discussion on this emerged over in select()'s unambiguous specialization resolution fails with platform constraint_value()s bazel#14604 (comment)

Thanks so much for your consideration!
Chris
(ex-Googler)

[aiuto]

I would start with the assumption that we want to eliminate/reduce the surface of @bazel_tools//src/conditions. If Bazel needs those conditions to build itself, then it can import them from a package, or declare them in its own BUILD files. To put it in a different light, the set or platforms we need for building Bazel is a completely distinct thing from the set of platforms that people build for.

But then does it serve everyone best to move them here? It seems to me that the android platforms should come with the android toolchains, and the apple ones with rules_apple.

[cpsauer]

@aiuto, to try to answer the above (slowly, sorry): I do still think so.

As a concrete motivating example: cc_libraries (like boost, for example) need to use them to select on, e.g, backends, but don't/shouldn't otherwise require rules_apple. (Boost is one of the several places I've reimplemented this, I think, and what prompted the comment above and our parallel discussion in #37.) This is the same reasoning, I'd think, that, e.g., @platforms//os:macos lives here rather than rules_apple. More generally, isn't the general philosophy to try to have general, universally selectable platforms logic live here?

That is, offhand, I'd favor having knowledge about which platforms exist centralized here, for all the same good reasons it is already, with knowledge about how to build for them being federated.

[cpsauer]

FWIW, seeing this duplicated again, contributing to boringssl. Still think the cross product would be valuable here--entirely parallel reasons to boost; these cross platform native libraries don't (and shouldn't) pull in rules_apple, android, etc. That is, it seems to me like the best acyclic dependency graph for reusability would be to put them here and reuse those defs for Bazel, boost, boringssl, apple, android, etc.