OLD | NEW |
1 # The MB (Meta-Build wrapper) design spec | 1 # The MB (Meta-Build wrapper) design spec |
2 | 2 |
3 [TOC] | 3 [TOC] |
4 | 4 |
5 ## Intro | 5 ## Intro |
6 | 6 |
7 MB is intended to address two major aspects of the GYP -> GN transition | 7 MB is intended to address two major aspects of the GYP -> GN transition |
8 for Chromium: | 8 for Chromium: |
9 | 9 |
10 1. "bot toggling" - make it so that we can easily flip a given bot | 10 1. "bot toggling" - make it so that we can easily flip a given bot |
(...skipping 28 matching lines...) Expand all Loading... |
39 ### Configurations | 39 ### Configurations |
40 | 40 |
41 `mb` looks in the `//tools/mb/mb_config.pyl` config file to determine whether | 41 `mb` looks in the `//tools/mb/mb_config.pyl` config file to determine whether |
42 to use GYP or GN for a particular build directory, and what set of flags | 42 to use GYP or GN for a particular build directory, and what set of flags |
43 (`GYP_DEFINES` or `gn args`) to use. | 43 (`GYP_DEFINES` or `gn args`) to use. |
44 | 44 |
45 A config can either be specified directly (useful for testing) or by specifying | 45 A config can either be specified directly (useful for testing) or by specifying |
46 the master name and builder name (useful on the bots so that they do not need | 46 the master name and builder name (useful on the bots so that they do not need |
47 to specify a config directly and can be hidden from the details). | 47 to specify a config directly and can be hidden from the details). |
48 | 48 |
| 49 MB can also be configured to take the list of GYP_DEFINES and gn args from |
| 50 the caller if necessary, using the "passthrough" mode. |
| 51 |
49 See the [user guide](user_guide.md#mb_config.pyl) for details. | 52 See the [user guide](user_guide.md#mb_config.pyl) for details. |
50 | 53 |
51 ### Handling the analyze step | 54 ### Handling the analyze step |
52 | 55 |
53 The interface to `mb analyze` is described in the | 56 The interface to `mb analyze` is described in the |
54 [user\_guide](user_guide.md#mb_analyze). | 57 [user\_guide](user_guide.md#mb_analyze). |
55 | 58 |
56 Since the interface basically mirrors the way the "analyze" step on the bots | 59 Since the interface basically mirrors the way the "analyze" step on the bots |
57 invokes gyp\_chromium today, when the config is found to be a gyp config, | 60 invokes gyp\_chromium today, when the config is found to be a gyp config, |
58 the arguments are passed straight through. | 61 the arguments are passed straight through. |
(...skipping 91 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... |
150 * Some common flags (goma\_dir being the obvious one) may need to be | 153 * Some common flags (goma\_dir being the obvious one) may need to be |
151 specified via the user, and it's unclear how to integrate this with | 154 specified via the user, and it's unclear how to integrate this with |
152 the concept of build\_configs. | 155 the concept of build\_configs. |
153 | 156 |
154 Right now, MB has hard-coded support for a few flags (i.e., you can | 157 Right now, MB has hard-coded support for a few flags (i.e., you can |
155 pass the --goma-dir flag, and it will know to expand "${goma\_dir}" in | 158 pass the --goma-dir flag, and it will know to expand "${goma\_dir}" in |
156 the string before calling out to the tool. We may want to generalize | 159 the string before calling out to the tool. We may want to generalize |
157 this to a common key/value approach (perhaps then meeting the | 160 this to a common key/value approach (perhaps then meeting the |
158 ChromeOS non-goal, above), or we may want to keep this very strictly | 161 ChromeOS non-goal, above), or we may want to keep this very strictly |
159 limited for simplicity. | 162 limited for simplicity. |
OLD | NEW |