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

[Gustavo Sverzut Barbieri]

On Wed, Apr 14, 2010 at 4:16 PM, Evan Martin <evan at chromium.org> wrote:
> 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

actually we were using automake to share with gtk, but it is becoming
a mess and we're trying to help clean it. as it might not happen we
are almost done with a cmake version... adding even more entropy :-P


> 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

EFL port is fine with whatever builds. As I just finished writing the
CMake based on autotools from GTK with quick look at Qt's and others,
I can give some useful input and review:

  1. generators need to be normalized, really. At least input/output
files need conversions to help them to be made by automatic rules.
Some scripts take input and output as parameters, some assumes files
are in the current directory and generates others in the current
directory. Others reads such information from .in makefiles and can
generate file names that are impossible to guess from the command
itself without reading the actual input files! :-(   DerivedSources...
but also generated sources elsewhere... needs to normalize it as well.

   2. while common parts are pretty straightforward to share, the
number of customization options makes the system a mess. That was one
of the biggest problems of sharing autotools with GTK, the "if OPTION
then SOMETHING endif" became huge.   Most of the "SOMETHING" is quite
similar, so if we enforce naming schemes we can have general rules
that does something like:   Option$PORT.xyz, and it will work for all
ports that supports it.   Having a configuration system that shares is
also important, be them xml/txt/whatever, but something that we can
say "EFL supports DATABASE, ..., but not VIDEO", new options would
trigger a warning to help developers, the options would be generated
based on the port support.

BR,

-- 
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--------------------------------------
MSN: barbieri at gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202