| 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 |
| 11 back and forth between GN and GYP. | 11 back and forth between GN and GYP. |
| 12 | 12 |
| 13 2. "bot configuration" - provide a single source of truth for all of | 13 2. "bot configuration" - provide a single source of truth for all of |
| 14 the different configurations (os/arch/`gyp_define` combinations) of | 14 the different configurations (os/arch/`gyp_define` combinations) of |
| 15 Chromium that are supported. | 15 Chromium that are supported. |
| 16 | 16 |
| 17 MB must handle at least the `gen` and `analyze` steps on the bots, i.e., | 17 MB must handle at least the `gen` and `analyze` steps on the bots, i.e., |
| 18 we need to wrap both the `gyp_chromium` invocation to generate the | 18 we need to wrap both the `gyp_chromium` invocation to generate the |
| 19 Ninja files, and the `analyze` step that takes a list of modified files | 19 Ninja files, and the `analyze` step that takes a list of modified files |
| 20 and a list of targets to build and returns which targets are affected by | 20 and a list of targets to build and returns which targets are affected by |
| 21 the files. | 21 the files. |
| 22 | 22 |
| 23 For more information on how to actually use MB, see |
| 24 [the user guide](user_guide.md). |
| 25 |
| 23 ## Design | 26 ## Design |
| 24 | 27 |
| 25 MB is intended to be as simple as possible, and to defer as much work as | 28 MB is intended to be as simple as possible, and to defer as much work as |
| 26 possible to GN or GYP. It should live as a very simple Python wrapper | 29 possible to GN or GYP. It should live as a very simple Python wrapper |
| 27 that offers little in the way of surprises. | 30 that offers little in the way of surprises. |
| 28 | 31 |
| 29 ### Command line | 32 ### Command line |
| 30 | 33 |
| 31 It is structured as a single binary that supports a list of subcommands: | 34 It is structured as a single binary that supports a list of subcommands: |
| 32 | 35 |
| (...skipping 82 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... |
| 115 | 118 |
| 116 Instead, we have one config per unique combination of flags only. | 119 Instead, we have one config per unique combination of flags only. |
| 117 | 120 |
| 118 In other words, rather than having `linux_rel_bot`, `win_rel_bot`, and | 121 In other words, rather than having `linux_rel_bot`, `win_rel_bot`, and |
| 119 `mac_rel_bot`, we just have `rel_bot`. | 122 `mac_rel_bot`, we just have `rel_bot`. |
| 120 | 123 |
| 121 This design allows us to determine easily all of the different sets | 124 This design allows us to determine easily all of the different sets |
| 122 of flags that we need to support, but *not* which flags are used on which | 125 of flags that we need to support, but *not* which flags are used on which |
| 123 host/target combinations. | 126 host/target combinations. |
| 124 | 127 |
| 125 It may be that we should really track the latter. Doing so is just a | 128 It may be that we should really track the latter. Doing so is just a |
| 126 config file change, however. | 129 config file change, however. |
| 127 | 130 |
| 128 ### Non-goals | 131 ### Non-goals |
| 129 | 132 |
| 130 * MB is not intended to replace direct invocation of GN or GYP for | 133 * MB is not intended to replace direct invocation of GN or GYP for |
| 131 complicated build scenarios (aka ChromeOS), where multiple flags need | 134 complicated build scenarios (aka ChromeOS), where multiple flags need |
| 132 to be set to user-defined paths for specific toolchains (e.g., where | 135 to be set to user-defined paths for specific toolchains (e.g., where |
| 133 ChromeOS needs to specify specific board types and compilers). | 136 ChromeOS needs to specify specific board types and compilers). |
| 134 | 137 |
| 135 * MB is not intended at this time to be something developers use frequently, | 138 * MB is not intended at this time to be something developers use frequently, |
| 136 or to add a lot of features to. We hope to be able to get rid of it once | 139 or to add a lot of features to. We hope to be able to get rid of it once |
| 137 the GYP->GN migration is done, and so we should not add things for | 140 the GYP->GN migration is done, and so we should not add things for |
| 138 developers that can't easily be added to GN itself. | 141 developers that can't easily be added to GN itself. |
| 139 | 142 |
| 140 * MB is not intended to replace the | 143 * MB is not intended to replace the |
| 141 [CR tool](https://code.google.com/p/chromium/wiki/CRUserManual). Not | 144 [CR tool](https://code.google.com/p/chromium/wiki/CRUserManual). Not |
| 142 only is it only intended to replace the gyp\_chromium part of `'gclient | 145 only is it only intended to replace the gyp\_chromium part of `'gclient |
| 143 runhooks'`, it is not really meant as a developer-facing tool. | 146 runhooks'`, it is not really meant as a developer-facing tool. |
| 144 | 147 |
| 145 ### Open issues | 148 ### Open issues |
| 146 | 149 |
| 147 * Some common flags (goma\_dir being the obvious one) may need to be | 150 * Some common flags (goma\_dir being the obvious one) may need to be |
| 148 specified via the user, and it's unclear how to integrate this with | 151 specified via the user, and it's unclear how to integrate this with |
| 149 the concept of build\_configs. | 152 the concept of build\_configs. |
| 150 | 153 |
| 151 Right now, MB has hard-coded support for a few flags (i.e., you can | 154 Right now, MB has hard-coded support for a few flags (i.e., you can |
| 152 pass the --goma-dir flag, and it will know to expand "${goma\_dir}" in | 155 pass the --goma-dir flag, and it will know to expand "${goma\_dir}" in |
| 153 the string before calling out to the tool. We may want to generalize | 156 the string before calling out to the tool. We may want to generalize |
| 154 this to a common key/value approach (perhaps then meeting the | 157 this to a common key/value approach (perhaps then meeting the |
| 155 ChromeOS non-goal, above), or we may want to keep this very strictly | 158 ChromeOS non-goal, above), or we may want to keep this very strictly |
| 156 limited for simplicity. | 159 limited for simplicity. |
| OLD | NEW |