[webkit-dev] [webkit meeting notes] build systems

[Evan Martin]

On Tuesday some people gathered to discuss the build-system bingo
within WebKit and what we can do to reduce (if not unify) the number
of project files you need to modify when you rename a file.  I took
the stage as a representative of Chromium's gyp project (I am
responsible for its Linux Makefile generator).

Here's a quick list of the different ports I'm aware of and their
build systems.  (Sorry for the non-monospaced tabbing, hope it comes
out ok...)

mac        xcode
win          vcproj
qt            qmake (cross-platform output)
gtk          autotools
android    Android.mk  (I heard rumors Android isn't actually upstream
yet, though (?))
chrome    gyp  (cross-platform output)
haiku       jam (?)
brew        waf (?)

derivative builds:
rim          hacked version of qt (qmake)
efl           qmake
sony        autotools (like gtk)
wincairo   win + vsprops
wince       like wincairo (different platforms: use a tree of vcproj)
air           hacked win (?)

Nobody is happy with the current situation where you must edit seven
files to avoid breaking someone's build; the question is what concrete
steps can improve it.  Everyone present seemed at least mildly
positive on migrating to other systems, though everyone is also
understandably skeptical of how much work would be involved.

We (Googlers) built gyp to deal with this exact problem -- building
Chrome (including WebKit) on Win/Mac/Linux while still producing
natural build files for the existing IDEs.  (On Linux, we generate
non-recursive Makefiles that get dependencies correct.)  It would take
a non-zero amount of work to use it for building things that are not
Chrome, as in one interpretation gyp's input data is kind of just a
glorified ls -R in JSON syntax, but it has worked well for us.

In general, the more complicated your platform gets (like the many
varieties of WinCE out there) the more complicated your build system
needs are, so I expect those would be the most work to change.  (For
example, the RIM build generates Makefiles on Windows but doesn't use
Visual Studio or the MS compiler, which is pretty esoteric from a
build system feature checklist perspective.  On the other hand, they
said it takes 7 minutes to finish generation on a fast computer, so
they might be more interested than others in alternatives.)

But particularly for the relatively simple builds (like the win/mac
ports) it is likely that gyp would be adequate without much work.
Perhaps they could serve as a proving ground for gyp.

Concretely, I'd propose:
- strongly encourage newer ports to hook on to an existing build,
since new build systems add overhead for everyone
- chromium/gyp developers should prove gyp by making it build a
non-chromium port; that includes subtasks of
  - getting the gyp+jsc build working again (it has worked in the past)
  - see how close to the existing mac/win build files we can get with gyp

In particular, if we can generate build files like the Apple Windows
WebKit port, there are other projects like the Windows Cairo build and
the WinCE work that could hopefully benefit with minor tweaking.

>From there, it would probably fall on other builds (qmake, autotools)
to see if they can benefit from gyp's shared file lists.  From my
brief tinkering with the GTK build I think I could generate
Makefile.am's pretty easily; I lack experience with qmake.  But I also
think it would be a good thing to simply reduce the number of build
systems