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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev