codekingpro/portable-devtools

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