@@ -302,12 +302,128 @@ If you're designing rules for a new language, we *strongly* encourage you to use
302
302
platforms to select your language' s toolchains. See
303
303
the [toolchains documentation](toolchains.html) for a good walkthrough.
304
304
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)
306
422
or the owners of the appropriate rules.
307
423
308
424
For discussions on the design and evolution of the platform/toolchain APIs,
309
425
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 ).
311
427
312
428
# # See also
313
429
0 commit comments