![]() Gyp has rudimentary cross compile support. Projects for all platforms is hard with Cmake (requires distribution toĦ. Means that for instance generating a tarball containing pregenerated Windows (cmake uses mac specific libraries to do project generation). For example xcode projects cannot be generated from CMake is not able to generate all projectįiles on all platforms. The project, rather each gyp file expresses knowledge about its immediate This avoids their being a single top level view of Additionally, all of the transitive dependencies of Settings without module A being filled with assumptions/knowledge of exactly When module A depends on module B, it automatically acquires the right build Include_dirs, defines, platforms specific settings, etc. Publish a set of direct_dependent_settings, specifying things like Strong notion of module public/private interface. In many cases, not all projectįile constructs correspond to command line flags.Ĥ. With a gyp stanza that does the equivalent. When somebody wants to use a particular menu option from msvs, I'm able toĭo a web search on the name of the setting from the IDE and provide them Things like: manifest generation, precompiled headers, bundle generation. The IDEs rather than reverse engineering them possibly incorrectly for This allows you to use abstractions built into In gyp's syntax you can add nearly any option present in a hand ![]() Abstraction on the level of project settings, rather than command lineįlags. CMake byĬomparison makes a good faith attempt to use native project features, butįalls back on generated scripts in order to preserve the same semantics onģ. Generated Makefiles/shell scripts to emulate some common abstraction. Of the platform specific project file formats, rather than falling back on Gyp was to support the least common denominator of features present in each This makes the resulting projectsĮasier to understand from the IDE and avoids parts of the IDE that simplyĭon't function correctly if you use Makefile projects. Itĭoesn't generate any Makefile type projects, but instead produces msvsĬustom Build Steps and Custom Build Rules. Windows, to generate vcprojs which resemble hand generated projects. Generation of a more 'normal' vcproj file. Their existing workflow, and only affected modules that had been converted.Ģ. Of the team wasn't even aware they were using gyp, as it integrated into During early stages of the transition, the majority The bottom up, largely because modules like base were easier to convert, and Regarding manipulating the raw sln/vcprojs. To this day we still have a good number of GUIDs pinned in the gyp files,īecause different parts of our release pipeline have leftover assumptions Substantial period of time, we had a hybrid of checked in vcproj and gyp generated Time and failed, due to the requirement to transition while in flight. Previous attempts to move to scons had taken a long Ability to incrementally transition on Windows. Google with large projects built wholly from source, leading to featuresĪbsent from cmake, but not strictly required for Chromium.ġ. Also, some of the design of gyp was informed by experience at There were a number of motivations, not all of which would apply to other I did an exploratory port of portions of Chromium to cmake (I think I got asįar as net, base, sandbox, and part of webkit). What motivated gyp's development, since we were aware of cmake at the time ![]() While back on the gyp-developers list in response to Mike Craddick regarding Here's the innards of an email with a laundry list of stuff I came up with a The text below is copied from CMake as a build system? ![]() Bradley Nelson wrote up the following description of why the team created GYP instead of using CMake. The functionality of GYP is very similar to the CMake build tool. Writing find modules is very annoying, especially when the upstream has put in the effort to create CMake package configuration files.GYP was originally created to generate native IDE project files (Visual Studio, Xcode) for building Chromium. This find module will have to locate the Bazel-produced artifacts and replicate upstream ccd's interface, including variable and target naming. Write your own Findccd.cmake find module, setting the cache variable CMAKE_MODULE_PATH in fcl's build to whichever directory in your source tree contains it.Use CMake to build ccd to get it to generate the correct package configuration files.But since you went through Bazel, that file will not exist. If you had that file, I would suggest setting the cache variable ccd_ROOT to whichever local prefix into which you have installed ccd. You have shot yourself in the foot, here.įcl's find_package statement is going to search for a file called ccd-config.cmake, using the search procedure documented here: How can I get the find_package statement to find the package that I build? I build that package as well, but just using cc_library. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |