Skip to content

Commit 23bd69d

Browse files
committed
Restore missing Building with Platforms docs.
Also update to correct mailing lists. Fixes #11581. PiperOrigin-RevId: 315890712
1 parent c063b5c commit 23bd69d

File tree

1 file changed

+118
-2
lines changed

1 file changed

+118
-2
lines changed

site/docs/platforms-intro.md

Lines changed: 118 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -302,12 +302,128 @@ If you're designing rules for a new language, we *strongly* encourage you to use
302302
platforms to select your language's toolchains. See
303303
the [toolchains documentation](toolchains.html) for a good walkthrough.
304304
305-
[[email protected]](https://groups.google.com/a/google.com/g/bazel-configurability).
305+
### `select()`
306+
Projects can [`select()`](configurable-attributes.html) on
307+
[`constraint_value`](be/platform.html#constraint_value)s but not complete
308+
platforms. This is intentional: we want `select()`s to support as wide a variety
309+
of machines as possible. A library with `ARM`-specific sources should support
310+
*all* `ARM`-powered machines unless there's reason to be more specific.
311+
312+
To select on one or more `constraint_value`s, use
313+
314+
```python
315+
config_setting(
316+
name = "is_arm",
317+
constraint_values = [
318+
"@platforms//cpu:arm",
319+
],
320+
)
321+
```
322+
323+
This is equivalent to traditionally selecting on `--cpu`:
324+
325+
```python
326+
config_setting(
327+
name = "is_arm",
328+
values = {
329+
"cpu": "arm",
330+
},
331+
)
332+
```
333+
334+
More details [here](configurable-attributes.html#platforms).
335+
336+
`select`s on `--cpu`, `--crosstool_top`, etc. don't understand `--platforms`. When
337+
migrating your project to platforms, you must either convert them to
338+
`constraint_values` or use [platform mappings](#platform-mappings) to support
339+
both styles through the migration window.
340+
341+
### Transitions
342+
[Starlark transitions](skylark/config.html#user-defined-transitions) change
343+
flags down parts of your build graph. If your project uses a transition that
344+
sets `--cpu`, `--crossstool_top`, or other legacy flags, rules that read
345+
`--platforms` won't see these changes.
346+
347+
When migrating your project to platforms, you must either convert changes like
348+
`return { "//command_line_option:cpu": "arm" }` to `return {
349+
"//command_line_options:platforms": "//:my_arm_platform" }` or use [platform
350+
mappings](#platform-mappings) to support both styles through the migration
351+
window.
352+
353+
## How to use platforms today
354+
If you just want to build or cross-compile a project, you should follow the
355+
project's official documentation. It's up to language and project maintainers to
356+
determine how and when to integrate with platforms, and what value that offers.
357+
358+
If you're a project, language, or toolchain maintainer and your build doesn't
359+
use platforms by default, you have three options (besides waiting for the global
360+
migration):
361+
362+
1. Flip on the "use platforms" flag for your project's languages ([if they have
363+
one](#status)) and do whatever testing you need to see if the projects you care
364+
about work.
365+
366+
1. If the projects you care about still depend on legacy flags like `--cpu` and
367+
`--crosstool_top`, use these together with `--platforms`:
368+
369+
370+
`$ bazel build //:my_mixed_project --platforms==//:myplatform
371+
--cpu=... --crosstool_top=...`
372+
373+
This has some maintenance cost (you have to manually make sure the settings
374+
match). But this should work in the absense of renegade
375+
[transitions](#transitions).
376+
377+
1. Write [platform mappings](#platform-mappings) to support both styles by
378+
mapping `--cpu`-style settings to corresponding platforms and vice versa.
379+
380+
### Platform mappings
381+
*Platform mappings* is a temporary API that lets platform-powered and
382+
legacy-powered logic co-exist in the same build through the latter's deprecation
383+
window.
384+
385+
A platform mapping is a map of either a `platform()` to a
386+
corresponding set of legacy flags or the reverse. For example:
387+
388+
```python
389+
platforms:
390+
# Maps "--platforms=//platforms:ios" to "--cpu=ios_x86_64 --apple_platform_type=ios".
391+
//platforms:ios
392+
--cpu=ios_x86_64
393+
--apple_platform_type=ios
394+
395+
flags:
396+
# Maps "--cpu=ios_x86_64 --apple_platform_type=ios" to "--platforms=//platforms:ios".
397+
--cpu=ios_x86_64
398+
--apple_platform_type=ios
399+
//platforms:ios
400+
401+
# Maps "--cpu=darwin --apple_platform_type=macos" to "//platform:macos".
402+
--cpu=darwin
403+
--apple_platform_type=macos
404+
//platforms:macos
405+
```
406+
407+
Bazel uses this to guarantee all settings, both platform-based and
408+
legacy, are consistently applied throughout the build, including through
409+
[transitions](#transitions).
410+
411+
By default Bazel reads mappings from the `platform_mappings` file in your
412+
workspace root. You can also set
413+
`--platform_mappings=//:my_custom_mapping`.
414+
415+
See
416+
[here](https://docs.google.com/document/d/1Vg_tPgiZbSrvXcJ403vZVAGlsWhH9BUDrAxMOYnO0Ls/edit)
417+
for complete details.
418+
419+
## Questions
420+
For general support and questions about the migration timeline, contact
421+
[[email protected]](https://groups.google.com/forum/#!forum/bazel-discuss)
306422
or the owners of the appropriate rules.
307423
308424
For discussions on the design and evolution of the platform/toolchain APIs,
309425
contact
310-
[bazel-configurability@google.com](https://groups.google.com/a/google.com/g/bazel-configurability).
426+
[bazel-dev@googlegroups.com](https://groups.google.com/forum/#!forum/bazel-dev).
311427
312428
## See also
313429

0 commit comments

Comments
 (0)