Re: [webkit-dev] Please welcome GYP to the our dysfunctional build family
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
Re: [webkit-dev] Please welcome GYP to the our dysfunctional build family
On Mon, Jul 13, 2009 at 12:24 PM, Mark Mentovai m...@chromium.org wrote: We also considered CMake, and had it demonstrably working for some of our smaller projects as well. BTW, Mark's list of issues with CMake is non-exhaustive (we can share more if desired), but we're not trying to slag CMake - it's a good tool in a lot of ways, it just didn't happen to be the right fit for us. So perhaps the takeaway other ports should have from all this is not that we're selling GYP as the be-all, end-all build tool for everyone, we're simply noting that since it's in the tree and we're maintaining it, if other people want to make use of it too, they'd be welcome if it fits their needs the way it fits ours. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Please welcome GYP to the our dysfunctional build family
On Sun, Jul 12, 2009 at 5:38 AM, Adam Treat tr...@kde.org wrote: On Friday 10 July 2009 12:23:50 am Dimitri Glazkov wrote: Dear WebKiteurs, In our persisting quest to be more like a common WebKit port, we have added Chromium build files to the tree this afternoon. These files are WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi and they are the GYP include files. As you may know, we use GYP (http://code.google.com/p/gyp) for generating MSVC, XCode, Scons, and even Make projects for Chromium. We are rather fond of GYP. Perhaps it is because it allows us to maintain one set of project files for all three Chromium platforms; Gyp sounds remarkably similar to CMake to me. I've never heard of Gyp before so I don't know much more about it than what you've said in this email, but CMake has been around for quite sometime and is in very wide use in the Open Source community. Can you say what prompts the use of Gyp over a tool like CMake? From a quick glance at cmake's website, it seems that it's a build system and not a project file generator. I think it was pretty important to us to generate project files so that you can use the full power of each platform's IDE and toolchain. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Please welcome GYP to the our dysfunctional build family
Hi, I asked some similar questions on IRC. On Friday 10 July 2009 12:23:50 am Dimitri Glazkov wrote: As you may know, we use GYP (http://code.google.com/p/gyp) for generating MSVC, XCode, Scons, and even Make projects for Chromium. On Sun, Jul 12, 2009 at 5:38 AM, Adam Treat tr...@kde.org wrote: Gyp sounds remarkably similar to CMake to me. On Jul 12, 2009, at 7:42 AM, Jeremy Orlow jor...@chromium.org wrote: From a quick glance at cmake's website, it seems that it's a build system and not a project file generator. I think it was pretty important to us to generate project files so that you can use the full power of each platform's IDE and toolchain. You might want to take a closer look! ;) CMake generates the desired build environment. So, on Windows it generates visual studio projects, on Mac OS it generates Xcode projects, and on Linux it generates Makefiles. You can override this behavior to get some other target. It can also drive the entire build, but that's not how a lot of people use it. 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. -Brent___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Please welcome GYP to the our dysfunctional build family
You have improved my quality of life by several months. On Thu, Jul 9, 2009 at 9:34 PM, Jeremy Orlowjor...@chromium.org wrote: This makes me very, very, very happy. :-) On Thu, Jul 9, 2009 at 9:23 PM, Dimitri Glazkov dglaz...@chromium.org wrote: Dear WebKiteurs, In our persisting quest to be more like a common WebKit port, we have added Chromium build files to the tree this afternoon. These files are WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi and they are the GYP include files. As you may know, we use GYP (http://code.google.com/p/gyp) for generating MSVC, XCode, Scons, and even Make projects for Chromium. We are rather fond of GYP. Perhaps it is because it allows us to maintain one set of project files for all three Chromium platforms; or maybe because it lets us to do things like WebCore.gypi, where we can just mindlessly add all project files to the list and then use various neat GYP filtering facilities to narrow them down to sets that are relevant for specific builds; or maybe because it easifies creating cross-platform and cross-build-system targets, actions, and rules; or maybe because we just love saying Gyp! I don't truthfully know. What I do know is that starting now, we'd love for you to remember WebCore.gypi and JavaScriptCore.gypi when you are adding or removing files from WebCore or JavaScriptCore. Thanks to the power of GYP, you don't have worry whether this file will be used by Chromium: the rule is that if there's a project file change, it applies to the *.gypi files. The format is very simple and intuitive, a simple Python/JSONey list+dict. Thank you for your attention, men and women of WebKit. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Please welcome GYP to the our dysfunctional build family
I think our number of different build systems is getting out of hand. Since gyp is being successfully used to build across platforms, and maintained by people who also work on some WebKit ports (and can thus likely be adapted to our needs), I'd like to consider whether we can use it for Apple's ports, and maybe consider rolling it out to additional ports over time. The gyp strategy of creating platform- native project files sounds like a good general approach. - Maciej On Jul 9, 2009, at 9:23 PM, Dimitri Glazkov wrote: Dear WebKiteurs, In our persisting quest to be more like a common WebKit port, we have added Chromium build files to the tree this afternoon. These files are WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi and they are the GYP include files. As you may know, we use GYP (http://code.google.com/p/gyp) for generating MSVC, XCode, Scons, and even Make projects for Chromium. We are rather fond of GYP. Perhaps it is because it allows us to maintain one set of project files for all three Chromium platforms; or maybe because it lets us to do things like WebCore.gypi, where we can just mindlessly add all project files to the list and then use various neat GYP filtering facilities to narrow them down to sets that are relevant for specific builds; or maybe because it easifies creating cross-platform and cross-build-system targets, actions, and rules; or maybe because we just love saying Gyp! I don't truthfully know. What I do know is that starting now, we'd love for you to remember WebCore.gypi and JavaScriptCore.gypi when you are adding or removing files from WebCore or JavaScriptCore. Thanks to the power of GYP, you don't have worry whether this file will be used by Chromium: the rule is that if there's a project file change, it applies to the *.gypi files. The format is very simple and intuitive, a simple Python/JSONey list+dict. Thank you for your attention, men and women of WebKit. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Please welcome GYP to the our dysfunctional build family
We certainly would love to see that happen and gladly commit helping to make this happen. :DG On Fri, Jul 10, 2009 at 3:15 PM, Maciej Stachowiakm...@apple.com wrote: I think our number of different build systems is getting out of hand. Since gyp is being successfully used to build across platforms, and maintained by people who also work on some WebKit ports (and can thus likely be adapted to our needs), I'd like to consider whether we can use it for Apple's ports, and maybe consider rolling it out to additional ports over time. The gyp strategy of creating platform-native project files sounds like a good general approach. - Maciej On Jul 9, 2009, at 9:23 PM, Dimitri Glazkov wrote: Dear WebKiteurs, In our persisting quest to be more like a common WebKit port, we have added Chromium build files to the tree this afternoon. These files are WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi and they are the GYP include files. As you may know, we use GYP (http://code.google.com/p/gyp) for generating MSVC, XCode, Scons, and even Make projects for Chromium. We are rather fond of GYP. Perhaps it is because it allows us to maintain one set of project files for all three Chromium platforms; or maybe because it lets us to do things like WebCore.gypi, where we can just mindlessly add all project files to the list and then use various neat GYP filtering facilities to narrow them down to sets that are relevant for specific builds; or maybe because it easifies creating cross-platform and cross-build-system targets, actions, and rules; or maybe because we just love saying Gyp! I don't truthfully know. What I do know is that starting now, we'd love for you to remember WebCore.gypi and JavaScriptCore.gypi when you are adding or removing files from WebCore or JavaScriptCore. Thanks to the power of GYP, you don't have worry whether this file will be used by Chromium: the rule is that if there's a project file change, it applies to the *.gypi files. The format is very simple and intuitive, a simple Python/JSONey list+dict. Thank you for your attention, men and women of WebKit. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Please welcome GYP to the our dysfunctional build family
On 2009-07-09, at 21:23, Dimitri Glazkov wrote: Dear WebKiteurs, In our persisting quest to be more like a common WebKit port, we have added Chromium build files to the tree this afternoon. These files are WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi and they are the GYP include files. As you may know, we use GYP (http://code.google.com/p/gyp) for generating MSVC, XCode, Scons, and even Make projects for Chromium. When do you plan to land enough of the build system that it can be used to, y'know, build something? It's difficult to evaluate such a system in any serious fashion without seeing how it would work with our setup. - Mark smime.p7s Description: S/MIME cryptographic signature ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Please welcome GYP to the our dysfunctional build family
Dear WebKiteurs, In our persisting quest to be more like a common WebKit port, we have added Chromium build files to the tree this afternoon. These files are WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi and they are the GYP include files. As you may know, we use GYP (http://code.google.com/p/gyp) for generating MSVC, XCode, Scons, and even Make projects for Chromium. We are rather fond of GYP. Perhaps it is because it allows us to maintain one set of project files for all three Chromium platforms; or maybe because it lets us to do things like WebCore.gypi, where we can just mindlessly add all project files to the list and then use various neat GYP filtering facilities to narrow them down to sets that are relevant for specific builds; or maybe because it easifies creating cross-platform and cross-build-system targets, actions, and rules; or maybe because we just love saying Gyp! I don't truthfully know. What I do know is that starting now, we'd love for you to remember WebCore.gypi and JavaScriptCore.gypi when you are adding or removing files from WebCore or JavaScriptCore. Thanks to the power of GYP, you don't have worry whether this file will be used by Chromium: the rule is that if there's a project file change, it applies to the *.gypi files. The format is very simple and intuitive, a simple Python/JSONey list+dict. Thank you for your attention, men and women of WebKit. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Please welcome GYP to the our dysfunctional build family
This makes me very, very, very happy. :-) On Thu, Jul 9, 2009 at 9:23 PM, Dimitri Glazkov dglaz...@chromium.orgwrote: Dear WebKiteurs, In our persisting quest to be more like a common WebKit port, we have added Chromium build files to the tree this afternoon. These files are WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi and they are the GYP include files. As you may know, we use GYP (http://code.google.com/p/gyp) for generating MSVC, XCode, Scons, and even Make projects for Chromium. We are rather fond of GYP. Perhaps it is because it allows us to maintain one set of project files for all three Chromium platforms; or maybe because it lets us to do things like WebCore.gypi, where we can just mindlessly add all project files to the list and then use various neat GYP filtering facilities to narrow them down to sets that are relevant for specific builds; or maybe because it easifies creating cross-platform and cross-build-system targets, actions, and rules; or maybe because we just love saying Gyp! I don't truthfully know. What I do know is that starting now, we'd love for you to remember WebCore.gypi and JavaScriptCore.gypi when you are adding or removing files from WebCore or JavaScriptCore. Thanks to the power of GYP, you don't have worry whether this file will be used by Chromium: the rule is that if there's a project file change, it applies to the *.gypi files. The format is very simple and intuitive, a simple Python/JSONey list+dict. Thank you for your attention, men and women of WebKit. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
