wiki:May 2013 Meeting - Unifying Build Systems - Notes

Version 1 (modified by jmason@blackberry.com, 8 years ago) (diff)

--

May 2013 WebKit Contributors Meeting - Unifying Build Systems

Host: Mark Salsbury

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 27816 -> 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 wel

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