/proc/4/root/var/lang/lib/node_modules/npm/node_modules/node-gyp/gyp/docs
This explorer reads the filesystem of the server it runs on, so /workspace/user isn't present here. Browsing and the terminal still work against this server's own disk from /.
# vs. CMake GYP was originally created to generate native IDE project files (Visual Studio, Xcode) for building [Chromium](http://www.chromim.org). The functionality of GYP is very similar to the [CMake](http://www.cmake.org)build tool. Bradley Nelson wrote up the following description of why the teamcreated GYP instead of using CMake. The text below is copied fromhttp://www.mail-archive.com/webkit-dev@lists.webkit.org/msg11029.html ``` Re: [webkit-dev] CMake as a build system?Bradley NelsonMon, 19 Apr 2010 22:38:30 -0700 Here's the innards of an email with a laundry list of stuff I came up with awhile back on the gyp-developers list in response to Mike Craddick regardingwhat motivated gyp's development, since we were aware of cmake at the time(we'd even started a speculative port): I did an exploratory port of portions of Chromium to cmake (I think I got asfar as net, base, sandbox, and part of webkit).There were a number of motivations, not all of which would apply to otherprojects. Also, some of the design of gyp was informed by experience atGoogle with large projects built wholly from source, leading to featuresabsent from cmake, but not strictly required for Chromium. 1. Ability to incrementally transition on Windows. It took us about 6 monthsto switch fully to gyp. Previous attempts to move to scons had taken a longtime and failed, due to the requirement to transition while in flight. For asubstantial period of time, we had a hybrid of checked in vcproj and gyp generatedvcproj. To this day we still have a good number of GUIDs pinned in the gyp files,because different parts of our release pipeline have leftover assumptionsregarding manipulating the raw sln/vcprojs. This transition occurred fromthe bottom up, largely because modules like base were easier to convert, andhad a lower churn rate. During early stages of the transition, the majorityof the team wasn't even aware they were using gyp, as it integrated intotheir existing workflow, and only affected modules that had been converted. 2. Generation of a more 'normal' vcproj file. Gyp attempts, particularly onWindows, to generate vcprojs which resemble hand generated projects. Itdoesn't generate any Makefile type projects, but instead produces msvsCustom Build Steps and Custom Build Rules. This makes the resulting projectseasier to understand from the IDE and avoids parts of the IDE that simplydon't function correctly if you use Makefile projects. Our early hope withgyp was to support the least common denominator of features present in eachof the platform specific project file formats, rather than falling back ongenerated Makefiles/shell scripts to emulate some common abstraction. CMake bycomparison makes a good faith attempt to use native project features, butfalls back on generated scripts in order to preserve the same semantics oneach platforms. 3. Abstraction on the level of project settings, rather than command lineflags. In gyp's syntax you can add nearly any option present in a handgenerated xcode/vcproj file. This allows you to use abstractions built intothe IDEs rather than reverse engineering them possibly incorrectly forthings like: manifest generation, precompiled headers, bundle generation.When somebody wants to use a particular menu option from msvs, I'm able todo a web search on the name of the setting from the IDE and provide themwith a gyp stanza that does the equivalent. In many cases, not all projectfile constructs correspond to command line flags. 4. Strong notion of module public/private interface. Gyp allows targets topublish a set of direct_dependent_settings, specifying things likeinclude_dirs, defines, platforms specific settings, etc. This means thatwhen module A depends on module B, it automatically acquires the right buildsettings without module A being filled with assumptions/knowledge of exactlyhow module B is built. Additionally, all of the transitive dependencies ofmodule B are pulled in. This avoids their being a single top level view ofthe project, rather each gyp file expresses knowledge about its immediateneighbors. This keep local knowledge local. CMake effectively has a largeshared global namespace. 5. Cross platform generation. CMake is not able to generate all projectfiles on all platforms. For example xcode projects cannot be generated fromwindows (cmake uses mac specific libraries to do project generation). Thismeans that for instance generating a tarball containing pregeneratedprojects for all platforms is hard with Cmake (requires distribution toseveral machine types). 6. Gyp has rudimentary cross compile support. Currently we've added enoughfunctionality to gyp to support x86 -> arm cross compiles. Last I checkedthis functionality wasn't present in cmake. (This occurred later). That being said there are a number of drawbacks currently to gyp: 1. Because platform specific settings are expressed at the project filelevel (rather than the command line level). Settings which might otherwisebe shared in common between platforms (flags to gcc on mac/linux), end upbeing repeated twice. Though in fairness there is actually less sharing herethan you'd think. include_dirs and defines actually represent 90% of whatcan be typically shared. 2. CMake may be more mature, having been applied to a broader range ofprojects. There a number of 'tool modules' for cmake, which are shared in acommon community. 3. gyp currently makes some nasty assumptions about the availability ofchromium's hermetic copy of cygwin on windows. This causes you to eitherhave to special case a number of rules, or swallow this copy of cygwin as abuild time dependency. 4. CMake includes a fairly readable imperative language. Currently Gyp has asomewhat poorly specified declarative language (variable expansion happensin sometimes weird and counter-intuitive ways). In fairness though, gyp assumesthat external python scripts can be used as an escape hatch. Also gyp avoidsa lot of the things you'd need imperative code for, by having a nice targetsettings publication mechanism. 5. (Feature/drawback depending on personal preference). Gyp's syntax isDEEPLY nested. It suffers from all of Lisp's advantages and drawbacks. -BradN```