README.md
1# [Bazel Platforms](https://bazel.build)
2
3This repository houses all canonical
4[constraint_setting()](https://bazel.build/reference/be/platforms-and-toolchains#constraint_setting)s,
5[constraint_value()](https://bazel.build/reference/be/platforms-and-toolchains#constraint_value)s
6and
7[platform()](https://bazel.build/reference/be/platforms-and-toolchains#platform)s
8that are universally useful across languages and Bazel projects.
9
10For questions or concerns please email
11[[email protected]](mailto://[email protected]).
12
13# Motivation
14
15Constraints must be carefully organized to avoid fragmentation. If two different
16declarations for, say, cpu=x86_64 were to exist at the same time then select()
17statements and toolchain selection would stop working across languages and
18projects.
19
20# Process
21
22This repository only includes truly ubiquitous constraints.
23
24Most common constraints -- that is settings and values that can be used across
25projects - fall into specific areas like "Apple" or "Java". These are declared
26in those areas' respective repositories.
27
28A very few constraints (such as OS and cpu) are relevant for essentially all
29projects across all areas. These are what this repository is for.
30
31# Adding a canonical constraint value
32
33To add a new canonical constraint value, prepare a PR adding it to that the
34appropriate BUILD file.
35
36Note that even global constraint values are typically area values. For example,
37ios is an area value for the global setting os but belongs in the apple area.
38For the PR's reviewer(s) choose an owner of this repository plus an owner of the
39area repository this references..
40
41A constraint value should be:
42
43- semantically clear, particularly in its distinctions from other values of
44 the same setting
45
46- well-named: consistent with existing values of the same setting and easy to
47 understand at usage sites
48
49- well-documented
50
51Remember that this value will apply for the entire Bazel community and its
52semantics will be difficult to impossible to change once it starts being used.
53
54# Adding a canonical constraint setting
55
56New canonical constraint settings should be rare and well-justified.
57
58To add a new setting, prepare a design document according to Bazel's design
59review process. This document should explain the need for a new setting and why
60it belongs here vs. area-specific repositories. It should clearly explain
61semantics, initial values, and criteria for adding new values.
62
63Once the design is approved prepare a PR for the actual change. If any values
64are area-specific, include the area repositories' owners as reviewers.
65
66# Private changes to global constraints
67
68If you'd like to experiment with changes to global settings or values, you can
69fork this repo for experimental purposes. But in the interest of community
70health and interoperability please don't share your changes with anyone not
71involved with the experiment. For wider distribution, submit a proper change
72here.
73
74Note that you can declare constraint_values in your own repo that are members of
75the global constraint_settings. This lets you "extend" global settings within
76the confines of your own project. But don't do this if you expect other projects
77to use these changes - this can easily lead to fragmentation conflicts.
78
79If you need custom constaint_settings, just declare them in your own repo. They
80are, by definition, not global.
81
82If you really need a permanent global change and it isn't design-approved for
83this repo, start a thread on
84[GitHub](https://github.com/bazelbuild/bazel/discussions) to discuss options.
85