As we've discussed off-and-on for a while, one of the larger pain-points in working on WebKit today is the large number of build systems. Simple things, like adding, removing, or renaming a file take a lot more effort than they should.
There are a number of approaches we could take to addressing this problem. One of the major constraints is that folks would like to use familiar IDEs (e.g., Xcode, Visual Studio) to build and debug WebKit. That means we'll need some sort of meta-build system that can generate port-specific IDE projects. Looking around the web, there are a handful of systems that could do the job. Dimitri, Eric, and I have started experimenting with one such system, GYP. There are various trade-offs between GYP and other systems, such as CMake, that we've discussed on this list and at the WebKit meeting last year. Ultimately, I don't think it really matters which system we use. If someone else would like to take over the project, I'd be happy to let them choose whichever system they'd like to use. Our current plan is as follows: 1) Bring up a build of the Apple-Mac port using GYP. At this stage, we'll have two ways of building Apple-Mac, the existing xcodeproj build system and the fancy-pants GYP-generated xcodeproj build system. 2) Replace the manually created xcodeproj files with GYP generated xcodeproj files. Ideally, contributors wouldn't even know when this step occurred. They can continue to use the generated project files in exactly the same way they use the manually created project files today. This step will help us work out any kinks in the new project files. 3) Remove the xcodeproj files from svn.webkit.org and integrate the generation of xcodeproj files with the WebKit build / update scripts. At this point, contributors will notice that something has changed because there'll be one less build system to worry about keeping up to date! Once we finish these steps, we can repeat them for other build systems, systematically reducing the number of build systems we need to maintain. Currently, we have a fully working build of JavaScriptGlue and a mostly working build of JavaScriptCore using this system. Some folks have asked why we're bothering to convert JavaScriptGlue at all. Working with JavaScriptGlue has been helpful because it's like a reduced test case for WebCore. We might not end up actually changing its build system in the end (because it's only used by Apple-Mac and is deprecated), but bringing it up has taught us a lot about how GYP works, especially for WebKit. As we get further along towards these milestones, I'll send updates to webkit-dev, especially if contributors need to change what they're doing. If you'd like to follow along in more detail, you're welcome to CC yourself on the meta bug: https://bugs.webkit.org/show_bug.cgi?id=55018 Hopefully we'll be able to make this transition as smooth as possible. I'm sure there will be some rough spots, and I'd like to thank you all in advance for bearing with us. Thanks, Adam _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
