OLD | NEW |
1 # GN Frequently Asked Questions | 1 # GN Frequently Asked Questions |
2 | 2 |
3 [TOC] | 3 [TOC] |
4 | 4 |
5 ## How will the build be converted? | |
6 | |
7 We intend to build a second independent build in parallel to the GYP | |
8 build. Previous efforts to generate GYP as an intermediate stage proved | |
9 difficult. There will be some smaller set of bots compiling this build, | |
10 and we'll keep the GN build running on these configurations. | |
11 | |
12 ## What is unsupported in GN? | |
13 | |
14 The main features not supported in GN yet are: | |
15 * Mac/iOS bundles | |
16 | |
17 ## Where is the GN documentation? | 5 ## Where is the GN documentation? |
18 | 6 |
19 Rather than on a separate wiki, it is versioned with the tool. Run `gn | 7 GN has extensive built-in help, so you can run `gn help`, but you can |
20 help`. See also the [quick start](quick_start.md) guide and the | 8 also see all of the help on [the reference page](reference.md). See |
21 [language and operation details](language.md). | 9 also the [quick start](quick_start.md) guide and the [language and |
| 10 operation details](language.md). |
22 | 11 |
23 ## What is likely to break? | 12 ## Can I generate XCode or Visual Studio projects? |
24 | 13 |
25 Since common.gypi is not used for GN-generated GYP files, any rules | 14 You can generate skeleton (or wrapper) projects for Xcode, Visual Studio, |
26 there will no longer apply. There is a _lot_ of logic in there for many | 15 QTCreator, and Eclipse that will list the files and targets in the |
27 build configurations and various conditions where certain flags should | 16 build, but use Ninja to do the actual build. You cannot generate "real" |
28 or should not be used. Some of these build configurations aren't even | 17 projects that look like native ones like GYP could. |
29 supported any more. Some are run on other waterfalls or are used by | |
30 individuals manually setting GYP\_DEFINES on their local system. | |
31 | 18 |
32 ## Will XCode/Visual Studio still be supported? | |
33 | |
34 Visual Studio is supported. Visual Studio can be used as an IDE for code | |
35 browsing or debugging but Ninja is used for building. | |
36 Run `gn help gen` for more details. | 19 Run `gn help gen` for more details. |
37 | 20 |
38 XCode is not supported yet. We need help! | |
39 | |
40 ## I'm weird. Will my uncommon build mode be supported? | |
41 | |
42 One of the main benefits of the build changeover is that it will | |
43 encourage us to refactor the build system. The project has generally not | |
44 been as strict with build complexity and maintenance as we have with | |
45 source code, and a lot of cruft has accumulated. | |
46 | |
47 In most cases, we will want to rethink how build flags are supported. We | |
48 want to be more modular rather than throwing everything in the | |
49 common.gypi equivalent. The bar for additions at this level will be very | |
50 high, and we will need to figure out how to design certain build | |
51 features. If you are interested in some weird configurations, this will | |
52 likely make your life more difficult in the short term, but will | |
53 hopefully bring long-term benefits for everybody. | |
54 | |
55 In some cases, we may decide that the overhead of supporting your build | |
56 for BeOS running on a DEC Alpha is not in the interests of the project. | |
57 There will likely be discussions about where to draw the line, and how | |
58 to allow those who want to do weird things to do them cleanly without | |
59 negatively affecting the rest of the Chromium community. | |
60 | |
61 ## I'm only a little bit weird, will my development build flag be supported? | |
62 | |
63 Only if you do it yourself! | |
64 | |
65 Some features have build flags that turn on a debugging mode or switch | |
66 between internal/external builds. This can be supported, but as with | |
67 GYP, your team will have to add an maintain the support. | |
68 | |
69 ## I use supplement.gypi, what's the GN equivalent? | |
70 | |
71 Some projects use files called `supplement.gypi` to set build flags. GYP | |
72 looks in each directory under `src` and adds merges these files into the | |
73 build. The model is that then adding something to your gclient to add | |
74 something to your build (e.g `src-internal`) automatically sets flags. | |
75 | |
76 This behavior is fragile and mysterious. Some people get build flags and | |
77 they don't know why. If you remove the entry from your `.gclient` and | |
78 don't remove the directory you'll be stuck on an old version of the | |
79 flags/code and not know why. You can't have builds in the same checkout | |
80 with the corresponding flags on and off. Some people and projects were | |
81 abusing this behavior. | |
82 | |
83 In GN, such things should be done with build arguments (`gn args`) and | |
84 configured on your build directory when you set it up. For some people, | |
85 this will be an extra step. But it is explicit and clear, and you can | |
86 have multiple builds in the same checkout with different flags. | |
87 | |
88 ## How do I generate common build variants? | 21 ## How do I generate common build variants? |
89 | 22 |
90 In GN, args go with a build directory rather than being global in the | 23 In GN, args go with a build directory rather than being global in the |
91 environment. To edit the args for your `out/Default` build directory: | 24 environment. To edit the args for your `out/Default` build directory: |
92 | 25 |
93 ``` | 26 ``` |
94 gn args out/Default | 27 gn args out/Default |
95 ``` | 28 ``` |
96 | 29 |
97 You can set variables in that file: | 30 You can set variables in that file: |
98 | 31 |
99 * The default is a debug build. To do a release build add | 32 * The default is a debug build. To do a release build add |
100 `is_debug = false` | 33 `is_debug = false` |
101 * The default is a static build. To do a component build add | 34 * The default is a static build. To do a component build add |
102 `is_component_build = true` | 35 `is_component_build = true` |
103 * The default is a developer build. To do an official build, set | 36 * The default is a developer build. To do an official build, set |
104 `is_official_build = true` | 37 `is_official_build = true` |
105 * The default is Chromium branding. To do Chrome branding, set | 38 * The default is Chromium branding. To do Chrome branding, set |
106 `is_chrome_branded = true` | 39 `is_chrome_branded = true` |
107 | 40 |
108 ## How do I do cross-compiles? | 41 ## How do I do cross-compiles? |
109 | 42 |
110 GN has robust support for doing cross compiles and building things for | 43 GN has robust support for doing cross compiles and building things for |
111 multiple architectures in a single build. | 44 multiple architectures in a single build. |
112 | 45 |
113 See [GNCrossCompiles](cross_compiles.md) for more info. | 46 See [GNCrossCompiles](cross_compiles.md) for more info. |
| 47 |
| 48 ## Can I control what targets are built by default? |
| 49 |
| 50 Yes! If you create a group target called "default" in the top-level (root) |
| 51 build file, i.e., "//:default", GN will tell Ninja to build that by |
| 52 default, rather than building everything. |
OLD | NEW |