| | 1 | May 2013 WebKit Contributors Meeting - Unifying Build Systems |
| | 2 | |
| | 3 | Host: Mark Salsbury |
| | 4 | |
| | 5 | Scribe: Joe Mason |
| | 6 | |
| | 7 | Down to 5 build systems (from 7 at last year's talk): |
| | 8 | - XCode - Mac |
| | 9 | - Visual Studio (Win, WinCairo) |
| | 10 | - QMake (qt) |
| | 11 | - automake (gtk) |
| | 12 | - cmake (everybody else) |
| | 13 | |
| | 14 | cmake generates xproj files, vcproj files |
| | 15 | |
| | 16 | Advantages gyp had over cmake: |
| | 17 | - generated projects to be the same as hand-built projects |
| | 18 | - Mark says: this hasn't been a problem for me |
| | 19 | - they don't "feel" like Visual Studio projects (weird filenames, etc) |
| | 20 | - 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) |
| | 21 | - want to just have python installed |
| | 22 | - this was to get buy-in from Apple devs |
| | 23 | - both Gtk and Mac were seriously looking at gyp; had workarounds for all of apple's internal build requirements |
| | 24 | |
| | 25 | Can we just check in generated project files? |
| | 26 | - may still be the right way forward for Apple's build requirements |
| | 27 | |
| | 28 | Split problem into two parts: |
| | 29 | 1. What can we do to satisfy gtk, qt, etc -> everyone but apple/mac |
| | 30 | - includes Apple/Win |
| | 31 | 2. will apple/mac switch? |
| | 32 | - much more difficult problem due to internal buildsystem which requires no external tools |
| | 33 | - add cmake to webkit? (see boost+bjam) |
| | 34 | - can't check in xcode files generated by cmake because they're system dependant |
| | 35 | - hardcoded paths, reads the environment a lot |
| | 36 | - KitWare could be contracted to make cmake improvements |
| | 37 | - but they have in the past said that generating cross-system XCode files is just not going to work due to cmake architecture |
| | 38 | - also we still have the problem of people updating the xcode files |
| | 39 | |
| | 40 | We have only 1 Apple rep here, and it's his first week with them. So no direct feedback from Apple. |
| | 41 | |
| | 42 | Are there particular requirements for Qt? |
| | 43 | - qt itself is a framework, with QtWeb embedded |
| | 44 | - qt evaluated whether to convert to cmake internally; it was ok to build Qt projects, but not build Qt itself |
| | 45 | - need a table of everywhere Qt runs, is cmake available? |
| | 46 | - suggestion: make cmake produce .pro files - need to evaluate how much work there is |
| | 47 | - 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 |
| | 48 | - qmake has already needed editing to work with webkit |
| | 49 | |
| | 50 | Gtk progress: |
| | 51 | - builds webcore, not JSC |
| | 52 | - one dev is doing it in their spare hours, hope to have it done in 6 months |
| | 53 | |
| | 54 | Visual studio: |
| | 55 | - Apple Windows - has more flexibility, can use tools from out of tree |
| | 56 | - uses proprietary graphics libs, can be downloaded for free: people outside Apple can build it, but lots of hoops to jump through |
| | 57 | - 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 |
| | 58 | - some downstream ports |
| | 59 | - Visual Studio users tend to find cmake-generated project files to be acceptable |
| | 60 | - bug 27816 -> build apple/win with cmake (2 competing patches) -> not a lot of discussion on the patch |
| | 61 | - one approach for Windows (Patrick), one for WinCE (Mark), which could coexist: been sitting in review for a year, not a lot of discussion |
| | 62 | - main reason it hasn't landed is, will the Apple windows port use it? |
| | 63 | - if Brent signs up for it for WinCairo, dpranke will be happy to review and land it (or better Brent can review it himself) |
| | 64 | - Roger Fong is in charge of Apple Windows port, would probably be open to switching as wel |
| | 65 | |
| | 66 | Why have people chosen cmake when gyp was already available? |
| | 67 | - Gtk chose cmake because it includes the idea of installation which gyp is not interested in: gtk ships shared objects, not an end browser |
| | 68 | - Originally chose gyp because Apple seemed to be going in that direction |
| | 69 | - Gtk has settled on cmake now, won't go back even if gyp is resurrected |
| | 70 | - BlackBerry chose cmake largely because we had someone with cmake experience, and timing (didn't know if gyp would be ready) |
| | 71 | - 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 |
| | 72 | - gyp can do this; cmake cannot |
| | 73 | |
| | 74 | Tangent: using full paths to improve build times |
| | 75 | - blink is in the process of moving to this, data has been inconclusive, even on Windows (should have data in a month or so) |
| | 76 | - similar: gyp has smaller include paths per directory (ie. only rendering needs cairo to be included) but this doesn't have a large impact |
