Closed gregestren closed 5 years ago
Initially assigning to the domain expert. I have no opinions on specific schedule, but do think we should be ready to call this "fixed" by Bazel 1.0
Other known stakeholders: @aragos @lberki
@katre brought up a good point in an earlier discussion that Bazel's internal rules currently rely on CPU
and OS
definitions in @bazel_tools/platforms
. So we need to shift that dependency to the external repo in some safe way.
fyi @agoulti
Pinging @jayconrod: would it be helpful (or possible) to move the platform definitions in bazelbuild/rules_go into a new, shared repository?
I think it would be both helpful and possible, but the targets in @io_bazel_rules_go//go/toolchain
and @io_bazel_rules_go//go/platform
should continue to exist as aliases. In order to minimize confusion for users coming from the regular Go SDK, we should name platforms using goos
/ goarch
values, but it's fine if the actual definitions are somewhere else. We already declare aliases instead of constraint_values
for OSs are architectures that are also declared in @bazel_tools
.
Sounds good. I'll start investigating this more deeply and make sure to include you on PRs.
Design proposal: https://groups.google.com/d/msg/bazel-dev/qKNNatUi5HE/X9S_ysFuBAAJ
Also note https://github.com/bazelbuild/bazel/issues/7668 for config_setting
.
Status update: The repo exists. https://github.com/bazelbuild/platforms Work is underway by others to move Bazel over to it.
@gregestren I'm thinking whether to close this issue as done and create new one for the migration that rules team will own, or to move this one over.
I just didn't want to steal the issue from you without first asking :)
I think smaller, focused issues is a good idea when possible.
For next steps see "Migrating @bazel_tools to @platforms", by @hlopko.
Platforms is coming at an increasing pace and is essentially ready today from a technical perspective.
But practical use requires clearly defined platform() and constraint_setting / constraint_value definitions in BUILD files.
We don't want to fragment these definitions so, e.g., every project has its own independent
cpu
definition that's incompatible with all others. So incoming users need guidance about where to find existing definitions and when/where/how to responsibly define their own.This issue covers seeding a central repository for basic settings that are clearly common across projects. It won't be in any way complete now, since full definitions will inevitably require a lot of time and community back-and-forth. But it can at least frame this process by giving it a clear starting point and initial focus for users who aren't otherwise sure where to start.
This should hopefully be enough to get the ball rolling in a productive way for everyone, with the ultimate goal to be to advance platform adoption as universally and quickly as possible while maximally leveraging its promised "one definition to rule them all" benefits.