May 2013 WebKit Contributors Meeting - Unifying Build Systems Host: Mark Salisbury Scribe: Joe Mason Down to 5 build systems (from 7 at last year's talk): - XCode - Mac - Visual Studio (Win, WinCairo) - QMake (qt) - automake (gtk) - cmake (everybody else) cmake generates xproj files, vcproj files Advantages gyp had over cmake: - generated projects to be the same as hand-built projects - Mark says: this hasn't been a problem for me - they don't "feel" like Visual Studio projects (weird filenames, etc) - how do I change this flag for debugging? I know how to do it in Xcode, how do I do it in cmake? (Easier mapping in gyp than in cmake) - want to just have python installed - this was to get buy-in from Apple devs - both Gtk and Mac were seriously looking at gyp; had workarounds for all of apple's internal build requirements Can we just check in generated project files? - may still be the right way forward for Apple's build requirements Split problem into two parts: 1. What can we do to satisfy gtk, qt, etc -> everyone but apple/mac - includes Apple/Win 2. Will apple/mac switch? - much more difficult problem due to internal buildsystem which requires no external tools - add cmake to webkit? (see boost+bjam) - can't check in xcode files generated by cmake because they're system dependant - hardcoded paths, reads the environment a lot - KitWare could be contracted to make cmake improvements - but they have in the past said that generating cross-system XCode files is just not going to work due to cmake architecture - also we still have the problem of people updating the xcode files We have only 1 Apple rep here, and it's his first week with them. So no direct feedback from Apple. Are there particular requirements for Qt? - qt itself is a framework, with QtWeb embedded - qt evaluated whether to convert to cmake internally; it was ok to build Qt projects, but not build Qt itself - need a table of everywhere Qt runs, is cmake available? - suggestion: make cmake produce .pro files - need to evaluate how much work there is - this is a lot of work because it's an extra level of indirection; qmake handles a lot of corner cases that are different on each platform - qmake has already needed editing to work with webkit Gtk progress: - builds webcore, not JSC - one dev is doing it in their spare hours, hope to have it done in 6 months Visual studio: - Apple Windows - has more flexibility, can use tools from out of tree - uses proprietary graphics libs, can be downloaded for free: people outside Apple can build it, but lots of hoops to jump through - WinCairo - uses different .vcproj files than Apple windows -> trying to converge (WinCairo does not yet use VS 2010) - written by Brent Fulghram, he may be open to moving to cmake - some downstream ports - Visual Studio users tend to find cmake-generated project files to be acceptable - bug 72816 -> build apple/win with cmake (2 competing patches) -> not a lot of discussion on the patch - one approach for Windows (Patrick), one for WinCE (Mark), which could coexist: been sitting in review for a year, not a lot of discussion - main reason it hasn't landed is, will the Apple windows port use it? - if Brent signs up for it for WinCairo, dpranke will be happy to review and land it (or better Brent can review it himself) - Roger Fong is in charge of Apple Windows port, would probably be open to switching as well Why have people chosen cmake when gyp was already available? - Gtk chose cmake because it includes the idea of installation which gyp is not interested in: gtk ships shared objects, not an end browser - Originally chose gyp because Apple seemed to be going in that direction - Gtk has settled on cmake now, won't go back even if gyp is resurrected - BlackBerry chose cmake largely because we had someone with cmake experience, and timing (didn't know if gyp would be ready) - easier to add/remove files: include/exclude by pattern (ie. build all in render but RenderThemeBlackBerry), that way when someone adds platform-specific files they don't mess up the build system for your platforms - gyp can do this; cmake cannot Tangent: using full paths to improve build times - blink is in the process of moving to this, data has been inconclusive, even on Windows (should have data in a month or so) - similar: gyp has smaller include paths per directory (ie. only rendering needs cairo to be included) but this doesn't have a large impact