wiki:April 2012 Reducing build systems

Version 1 (modified by, 12 years ago) (diff)

First pass at notes.

Reducing build systems

Moderator: Eric Seidel, Scribe: Daniel Bates

Eric's notes

Currently WebKit has 7 build systems:

  • XCode (Mac)
  • Visual Studio (Win, WinCairo)
  • QMake (Qt)
  • AutoMake (Gtk)
  • CMake (EFL, Blackberry, WinCE)
  • GYP (Chromium Mac/Win/Linux/Android/etc.)
  • WAF (WX)

Problems with our current build systems:

  • Duplication of logic

*Difficulty adding files

Additional notes

Eric Seidel: My goal a year from now not to have 7 but to have 6, more aggressive goal is to have 5 or 4.

Eric Seidel: How many people have added a file to webkit? (Majority raised our hands.)

Q: Why to get rid of build systems? Eric Seidel: Remove build systems for simplicity.

Eric Seidel: Want to move rendering directories into a line box directory, thought can do that between sessions, but realized couldn't because its complicated.

Eric Seidel: One problem is that some build systems need to be edited using specialized tools.

Eric Seidel: We have too many build systems. I would like us to have 6.

Q: Are there other solutions than just reducing them? Could we share more? A: We could theoretically share more for systems that have a functional make. Having tooling, say add-build-file, to automate adding of new files to all build systems. Two people, related to Chromium, have written Xcode editing Python scripts that have been put up for review but haven't landed.

Q: Would there be alternative to having 6 files that list all files? A: Xcode cannot read a newline delimited text file of source files.

Eric Seidel: One of the things we did last year was split out the existing build systems...splitting out the logic for the build from the list of files. Meta systems are great at generating lists of files not good at generating logic.

Nate Chapin: Can we have a policy against new build systems when ports come in?

Eric Seidel: We don't.

Nate Chapin: Can we have one please?

Eric Seidel: The reality is when a new port comes along with a new build systems it doesn't matter. They are small, will get broken, and only half implemented.

Eric Seidel: Don't have an explicitly policy against having more build systems.

Q: What's blocking the Chromium Python patches? Dirk Pranke: Waiting to be broken up into logical chunks and reviewed.

Dirk Pranke: Have you thought of a script to pull data from gyp file to qmake? Tor Arne Vestbø: Would be possible to auto generate the list.

Eric Seidel: There exists things like meta build systems, which generates a build system. We're using three of them: CMake, qmake, gyp. My goal is to talk about using more of these [meta build systems]? Using qmake, CMake, gyp of the world instead of using Visual Studio or Xcode by itself.

Tor Arne Vestbø: When integrating with Qt can't have dependencies on Python.

Eric Seidel: Do you see the qmake pull a list of files from some other central repo/sys?

Tor Arne Vestbø: Yes. Qmake has support for reading an arbitrary text file for source files...Need some kind of if/def logic to include platform-specific files and exclude others

Steve Falkenburg: Looking to moving to Visual Studio 2010.

Eric Seidel: Have you started? Steve Falkenburg (Paraphrase): Part of the problem of both Apple ports is that we don't think we can run CMake for official builds.

Eric Seidel: May find value to have list of files and checkin the Xcode, Visual Stduio files. [We may] benefit from [an] add a file script. If the Apple ports are interested in a meta build system then just we checkin the files.

Another approach: scripts; requirements for such scripts

  1. Want add file, remove file, move file
  2. Central list of feature defines; "don't know a way to get there" (Eric Seidel)
  3. Ability to add/remove feature defines
  4. Change include paths
  5. Change file paths