Generate Your Projects, or GYP, was designed around Chromium's needs. Maintaining distinct project files for different build environments and different platforms put a great burden on our team, and was never intended to be a long-term solution. We really wanted to have a single canonical description of the build from which we could generate the native project files that developers were accustomed to.
One proposed solution was to treat our SCons build as canonical and have it generate native project files. This integration never really came to fruition. We had SCons generating Visual Studio projects for simpler projects, but mapping the flexible SCons input language to the more restrictive descriptions used in IDE project files proved difficult. We also considered CMake, and had it demonstrably working for some of our smaller projects as well. Unfortunately, transitioning to CMake would have required moving everything over at once, without allowing for some existing projects to be maintained "by hand" during a transition period. CMake-generated files contain absolute paths, so a .tar or .zip of the source tree could not be primed with CMake output, complicating the "bootstrapping" process for new contributors. A less significant factor was that CMake introduced an additional binary build prerequisite, which would have had to have been installed everywhere. Python is already a prerequisite for Chromium, so a Python tool was easier to deploy. The net result of all of this was GYP, which was designed specifically to meet Chromium's needs. We were able to get GYP to generate project files on all three of our main platforms fairly rapidly, and we designed for (and eventually executed on some platforms) a staged transition from the existing build. GYP helped Chromium solve more problems in less time than any of the other options that we experimented with, but it's important to remember that Chromium's needs are not necessarily the same as those of other projects. There are several valid ways to solve the "too many build systems" problem, and GYP just happens to be one that has worked well for us. Mark (Full disclosure: I'm the principal designer of GYP, and would be happy to discuss it in further detail) Brent Fulgham wrote: > So Cmake seems equivalent to GYP. GYP probably has unique features that make > it more desireable than Cmake for one reason or another (perhaps it's easier > to add new platform support or something), but at the moment those benefits > are not obvious to me. > I'm afraid that as far as I can tell, GYP seems like a case of NIH syndrome. _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev