OLD | NEW |
| (Empty) |
1 # GYP vs. CMake # | |
2 | |
3 GYP was originally created to generate native IDE project files (Visual Studio,
Xcode) for building [Chromium](http://www.chromim.org). | |
4 | |
5 The functionality of GYP is very similar to the [CMake](http://www.cmake.org) | |
6 build tool. Bradley Nelson wrote up the following description of why the team | |
7 created GYP instead of using CMake. The text below is copied from | |
8 http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg11029.html | |
9 | |
10 ``` | |
11 | |
12 Re: [webkit-dev] CMake as a build system? | |
13 Bradley Nelson | |
14 Mon, 19 Apr 2010 22:38:30 -0700 | |
15 | |
16 Here's the innards of an email with a laundry list of stuff I came up with a | |
17 while back on the gyp-developers list in response to Mike Craddick regarding | |
18 what motivated gyp's development, since we were aware of cmake at the time | |
19 (we'd even started a speculative port): | |
20 | |
21 | |
22 I did an exploratory port of portions of Chromium to cmake (I think I got as | |
23 far as net, base, sandbox, and part of webkit). | |
24 There were a number of motivations, not all of which would apply to other | |
25 projects. Also, some of the design of gyp was informed by experience at | |
26 Google with large projects built wholly from source, leading to features | |
27 absent from cmake, but not strictly required for Chromium. | |
28 | |
29 1. Ability to incrementally transition on Windows. It took us about 6 months | |
30 to switch fully to gyp. Previous attempts to move to scons had taken a long | |
31 time and failed, due to the requirement to transition while in flight. For a | |
32 substantial period of time, we had a hybrid of checked in vcproj and | |
33 gyp generated | |
34 vcproj. To this day we still have a good number of GUIDs pinned in the | |
35 gyp files, | |
36 because different parts of our release pipeline have leftover assumptions | |
37 regarding manipulating the raw sln/vcprojs. This transition occurred from | |
38 the bottom up, largely because modules like base were easier to convert, and | |
39 had a lower churn rate. During early stages of the transition, the majority | |
40 of the team wasn't even aware they were using gyp, as it integrated into | |
41 their existing workflow, and only affected modules that had been converted. | |
42 | |
43 2. Generation of a more 'normal' vcproj file. Gyp attempts, particularly on | |
44 Windows, to generate vcprojs which resemble hand generated projects. It | |
45 doesn't generate any Makefile type projects, but instead produces msvs | |
46 Custom Build Steps and Custom Build Rules. This makes the resulting projects | |
47 easier to understand from the IDE and avoids parts of the IDE that simply | |
48 don't function correctly if you use Makefile projects. Our early hope with | |
49 gyp was to support the least common denominator of features present in each | |
50 of the platform specific project file formats, rather than falling back on | |
51 generated Makefiles/shell scripts to emulate some common abstraction. CMake by | |
52 comparison makes a good faith attempt to use native project features, but | |
53 falls back on generated scripts in order to preserve the same semantics on | |
54 each platforms. | |
55 | |
56 3. Abstraction on the level of project settings, rather than command line | |
57 flags. In gyp's syntax you can add nearly any option present in a hand | |
58 generated xcode/vcproj file. This allows you to use abstractions built into | |
59 the IDEs rather than reverse engineering them possibly incorrectly for | |
60 things like: manifest generation, precompiled headers, bundle generation. | |
61 When somebody wants to use a particular menu option from msvs, I'm able to | |
62 do a web search on the name of the setting from the IDE and provide them | |
63 with a gyp stanza that does the equivalent. In many cases, not all project | |
64 file constructs correspond to command line flags. | |
65 | |
66 4. Strong notion of module public/private interface. Gyp allows targets to | |
67 publish a set of direct_dependent_settings, specifying things like | |
68 include_dirs, defines, platforms specific settings, etc. This means that | |
69 when module A depends on module B, it automatically acquires the right build | |
70 settings without module A being filled with assumptions/knowledge of exactly | |
71 how module B is built. Additionally, all of the transitive dependencies of | |
72 module B are pulled in. This avoids their being a single top level view of | |
73 the project, rather each gyp file expresses knowledge about its immediate | |
74 neighbors. This keep local knowledge local. CMake effectively has a large | |
75 shared global namespace. | |
76 | |
77 5. Cross platform generation. CMake is not able to generate all project | |
78 files on all platforms. For example xcode projects cannot be generated from | |
79 windows (cmake uses mac specific libraries to do project generation). This | |
80 means that for instance generating a tarball containing pregenerated | |
81 projects for all platforms is hard with Cmake (requires distribution to | |
82 several machine types). | |
83 | |
84 6. Gyp has rudimentary cross compile support. Currently we've added enough | |
85 functionality to gyp to support x86 -> arm cross compiles. Last I checked | |
86 this functionality wasn't present in cmake. (This occurred later). | |
87 | |
88 | |
89 That being said there are a number of drawbacks currently to gyp: | |
90 | |
91 1. Because platform specific settings are expressed at the project file | |
92 level (rather than the command line level). Settings which might otherwise | |
93 be shared in common between platforms (flags to gcc on mac/linux), end up | |
94 being repeated twice. Though in fairness there is actually less sharing here | |
95 than you'd think. include_dirs and defines actually represent 90% of what | |
96 can be typically shared. | |
97 | |
98 2. CMake may be more mature, having been applied to a broader range of | |
99 projects. There a number of 'tool modules' for cmake, which are shared in a | |
100 common community. | |
101 | |
102 3. gyp currently makes some nasty assumptions about the availability of | |
103 chromium's hermetic copy of cygwin on windows. This causes you to either | |
104 have to special case a number of rules, or swallow this copy of cygwin as a | |
105 build time dependency. | |
106 | |
107 4. CMake includes a fairly readable imperative language. Currently Gyp has a | |
108 somewhat poorly specified declarative language (variable expansion happens | |
109 in sometimes weird and counter-intuitive ways). In fairness though, gyp assumes | |
110 that external python scripts can be used as an escape hatch. Also gyp avoids | |
111 a lot of the things you'd need imperative code for, by having a nice target | |
112 settings publication mechanism. | |
113 | |
114 5. (Feature/drawback depending on personal preference). Gyp's syntax is | |
115 DEEPLY nested. It suffers from all of Lisp's advantages and drawbacks. | |
116 | |
117 -BradN | |
118 ``` | |
OLD | NEW |