1 +
# 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 gyp generated
33 +
vcproj. To this day we still have a good number of GUIDs pinned in the gyp files,
34 +
because different parts of our release pipeline have leftover assumptions
35 +
regarding manipulating the raw sln/vcprojs. This transition occurred from
36 +
the bottom up, largely because modules like base were easier to convert, and
37 +
had a lower churn rate. During early stages of the transition, the majority
38 +
of the team wasn't even aware they were using gyp, as it integrated into
39 +
their existing workflow, and only affected modules that had been converted.
40 + 41 +
2. Generation of a more 'normal' vcproj file. Gyp attempts, particularly on
42 +
Windows, to generate vcprojs which resemble hand generated projects. It
43 +
doesn't generate any Makefile type projects, but instead produces msvs
44 +
Custom Build Steps and Custom Build Rules. This makes the resulting projects
45 +
easier to understand from the IDE and avoids parts of the IDE that simply
46 +
don't function correctly if you use Makefile projects. Our early hope with
47 +
gyp was to support the least common denominator of features present in each
48 +
of the platform specific project file formats, rather than falling back on
49 +
generated Makefiles/shell scripts to emulate some common abstraction. CMake by
50 +
comparison makes a good faith attempt to use native project features, but
51 +
falls back on generated scripts in order to preserve the same semantics on
52 +
each platforms.
53 + 54 +
3. Abstraction on the level of project settings, rather than command line
55 +
flags. In gyp's syntax you can add nearly any option present in a hand
56 +
generated xcode/vcproj file. This allows you to use abstractions built into
57 +
the IDEs rather than reverse engineering them possibly incorrectly for
58 +
things like: manifest generation, precompiled headers, bundle generation.
59 +
When somebody wants to use a particular menu option from msvs, I'm able to
60 +
do a web search on the name of the setting from the IDE and provide them
61 +
with a gyp stanza that does the equivalent. In many cases, not all project
62 +
file constructs correspond to command line flags.
63 + 64 +
4. Strong notion of module public/private interface. Gyp allows targets to
65 +
publish a set of direct_dependent_settings, specifying things like
66 +
include_dirs, defines, platforms specific settings, etc. This means that
67 +
when module A depends on module B, it automatically acquires the right build
68 +
settings without module A being filled with assumptions/knowledge of exactly
69 +
how module B is built. Additionally, all of the transitive dependencies of
70 +
module B are pulled in. This avoids their being a single top level view of
71 +
the project, rather each gyp file expresses knowledge about its immediate
72 +
neighbors. This keep local knowledge local. CMake effectively has a large
73 +
shared global namespace.
74 + 75 +
5. Cross platform generation. CMake is not able to generate all project
76 +
files on all platforms. For example xcode projects cannot be generated from
77 +
windows (cmake uses mac specific libraries to do project generation). This
78 +
means that for instance generating a tarball containing pregenerated
79 +
projects for all platforms is hard with Cmake (requires distribution to
80 +
several machine types).
81 + 82 +
6. Gyp has rudimentary cross compile support. Currently we've added enough
83 +
functionality to gyp to support x86 -> arm cross compiles. Last I checked
84 +
this functionality wasn't present in cmake. (This occurred later).
85 + 86 + 87 +
That being said there are a number of drawbacks currently to gyp:
88 + 89 +
1. Because platform specific settings are expressed at the project file
90 +
level (rather than the command line level). Settings which might otherwise
91 +
be shared in common between platforms (flags to gcc on mac/linux), end up
92 +
being repeated twice. Though in fairness there is actually less sharing here
93 +
than you'd think. include_dirs and defines actually represent 90% of what
94 +
can be typically shared.
95 + 96 +
2. CMake may be more mature, having been applied to a broader range of
97 +
projects. There a number of 'tool modules' for cmake, which are shared in a
98 +
common community.
99 + 100 +
3. gyp currently makes some nasty assumptions about the availability of
101 +
chromium's hermetic copy of cygwin on windows. This causes you to either
102 +
have to special case a number of rules, or swallow this copy of cygwin as a
103 +
build time dependency.
104 + 105 +
4. CMake includes a fairly readable imperative language. Currently Gyp has a
106 +
somewhat poorly specified declarative language (variable expansion happens
107 +
in sometimes weird and counter-intuitive ways). In fairness though, gyp assumes
108 +
that external python scripts can be used as an escape hatch. Also gyp avoids
109 +
a lot of the things you'd need imperative code for, by having a nice target
110 +
settings publication mechanism.
111 + 112 +
5. (Feature/drawback depending on personal preference). Gyp's syntax is
113 +
DEEPLY nested. It suffers from all of Lisp's advantages and drawbacks.
114 + 115 +
-BradN
116 +
```
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4