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