Re: [webkit-dev] webkit-patch and SVN
On Wed, Apr 14, 2010 at 5:06 PM, Adam Barth aba...@webkit.org wrote: On Wed, Apr 14, 2010 at 4:52 PM, Geoffrey Garen gga...@apple.com wrote: I'd rather keep the current behavior and have it operate on the entire repository. I think it will be too easy to make mistakes and leave out large portions of a patch if it only operates upon the current working directory. That's a fixable mistake, though, if/when it happens. Taking huge amounts of time unnecessarily diff'ing the LayoutTests directory is a fixed cost that is unavoidable and unfixable. How long is a huge amount of time? Here are some stats from my laptop. In the first run, I suspect webkit was not in my disk cache (since I recently compiled another checkout): ~/svn/webkit3$ time svn diff real0m23.437s user0m1.936s sys 0m7.531s In the second run, I suspect webkit was in my disk cache: ~/svn/webkit3$ time svn diff real0m8.929s user0m2.019s sys 0m6.012s ~/svn/webkit3$ svn --version svn, version 1.6.3 (r38063) If the diff is taking much longer than these times, you probably have a borked SVN working copy. We've seen really slow working copies when the working copy was created with SVN 1.5 and then upgraded to 1.6. If your SVN is slow, you might consider blowing away your working copy and making a new one with SVN 1.6. Adam This may not seem like a huge difference, but 23 seconds is enough to encourage me to cd WebCore before running svn-create-patch or prepare-ChangeLog. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit-patch and SVN
On Wed, Apr 14, 2010 at 11:47 PM, Darin Fisher da...@chromium.org wrote: On Wed, Apr 14, 2010 at 5:06 PM, Adam Barth aba...@webkit.org wrote: On Wed, Apr 14, 2010 at 4:52 PM, Geoffrey Garen gga...@apple.com wrote: I'd rather keep the current behavior and have it operate on the entire repository. I think it will be too easy to make mistakes and leave out large portions of a patch if it only operates upon the current working directory. That's a fixable mistake, though, if/when it happens. Taking huge amounts of time unnecessarily diff'ing the LayoutTests directory is a fixed cost that is unavoidable and unfixable. How long is a huge amount of time? Here are some stats from my laptop. In the first run, I suspect webkit was not in my disk cache (since I recently compiled another checkout): ~/svn/webkit3$ time svn diff real 0m23.437s user 0m1.936s sys 0m7.531s In the second run, I suspect webkit was in my disk cache: ~/svn/webkit3$ time svn diff real 0m8.929s user 0m2.019s sys 0m6.012s ~/svn/webkit3$ svn --version svn, version 1.6.3 (r38063) If the diff is taking much longer than these times, you probably have a borked SVN working copy. We've seen really slow working copies when the working copy was created with SVN 1.5 and then upgraded to 1.6. If your SVN is slow, you might consider blowing away your working copy and making a new one with SVN 1.6. This may not seem like a huge difference, but 23 seconds is enough to encourage me to cd WebCore before running svn-create-patch or prepare-ChangeLog. Does that mean you're not writing tests for your changes? ;) I don't have a good sense for what SVN workflows are like. I've switched over to SVN for a bit to try to understand how it works, but I haven't learned all the tricks yet. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit-patch and SVN
On Thu, Apr 15, 2010 at 12:09 AM, Adam Barth aba...@webkit.org wrote: On Wed, Apr 14, 2010 at 11:47 PM, Darin Fisher da...@chromium.org wrote: On Wed, Apr 14, 2010 at 5:06 PM, Adam Barth aba...@webkit.org wrote: On Wed, Apr 14, 2010 at 4:52 PM, Geoffrey Garen gga...@apple.com wrote: I'd rather keep the current behavior and have it operate on the entire repository. I think it will be too easy to make mistakes and leave out large portions of a patch if it only operates upon the current working directory. That's a fixable mistake, though, if/when it happens. Taking huge amounts of time unnecessarily diff'ing the LayoutTests directory is a fixed cost that is unavoidable and unfixable. How long is a huge amount of time? Here are some stats from my laptop. In the first run, I suspect webkit was not in my disk cache (since I recently compiled another checkout): ~/svn/webkit3$ time svn diff real0m23.437s user0m1.936s sys 0m7.531s In the second run, I suspect webkit was in my disk cache: ~/svn/webkit3$ time svn diff real0m8.929s user0m2.019s sys 0m6.012s ~/svn/webkit3$ svn --version svn, version 1.6.3 (r38063) If the diff is taking much longer than these times, you probably have a borked SVN working copy. We've seen really slow working copies when the working copy was created with SVN 1.5 and then upgraded to 1.6. If your SVN is slow, you might consider blowing away your working copy and making a new one with SVN 1.6. This may not seem like a huge difference, but 23 seconds is enough to encourage me to cd WebCore before running svn-create-patch or prepare-ChangeLog. Does that mean you're not writing tests for your changes? ;) I don't have a good sense for what SVN workflows are like. I've switched over to SVN for a bit to try to understand how it works, but I haven't learned all the tricks yet. Adam It is common for me to re-create WebCore/ChangeLog as I modify my solution, and I've also worked on a fair number of patches that are just porting / getting existing tests to pass :-/ My workflow with svn is to work from a subdirectory if I can to minimize the cost of svn operations. If I need to work from the topmost directory, then I typically specify the directories I'm interested in on the svn command line (e.g., svn commit WebCore LayoutTests). That way the commands run faster. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Qt is now a core builder
One thing I noticed is that the Core-only waterfall does not show any changes
in the change column (because we're not sending them with any specific
category). If that bothers anyone, I can change the svn hooks. The console does
not have this problem.
-Bill
On Apr 15, 2010, at 6:22 AM, William Siegrist wrote:
The master has been reconfigured. Now there are two links, Core Console and
Core Waterfall on the main page which will show just the core builders. The
regular Console view also separates the builders by category, but will show
all of them.
-Bill
On Apr 14, 2010, at 9:17 AM, William Siegrist wrote:
I was thinking of something like the following, assuming we want to have
core builders still. The URL to see only core builders would be:
http://build.webkit.org/console?category=core
http://build.webkit.org/waterfall?category=core
... and we could use redirects or just add new links to the main page.
Index: master.cfg
===
--- master.cfg (revision 57518)
+++ master.cfg (working copy)
@@ -16,6 +16,8 @@
import re
import simplejson
+from webkitpy.common.net.buildbot import BuildBot as wkbuildbot
+
WithProperties = properties.WithProperties
class ConfigureBuild(buildstep.BuildStep):
@@ -369,6 +371,9 @@
config = simplejson.load(open('config.json'))
+# use webkitpy's buildbot module to test for core builders
+wkbb = wkbuildbot()
+
c['slaves'] = [BuildSlave(slave['name'], passwords[slave['name']],
max_builds=1) for slave in config['slaves']]
c['schedulers'] = []
@@ -397,6 +402,10 @@
builder[factory] = factory(*factoryArgs)
+builder[category] = noncore
+if wkbb._is_core_builder(builder['name']):
+builder[category] = core
+
c['builders'].append(builder)
loadBuilderConfig(c)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] svn stopped to commit into WebKit
Dear WebKitters, just a couple of moments ago svn stopped to commit into WebKit for me: svn: Commit blocked by pre-commit hook (exit code 1) with output: svnlook: Can't write to stream: Broken pipe The following files contain tab characters: trunk/LayoutTests/ChangeLog Please use spaces instead to indent. If you must commit a file with tabs, use svn propset to set the allow-tabs property. Any chances someone is changing pre-commit hooks? And if yes, was this change intentional? tia and yours, anton. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] svn stopped to commit into WebKit
On Apr 15, 2010, at 6:54 AM, Anton Muhin wrote: Dear WebKitters, just a couple of moments ago svn stopped to commit into WebKit for me: svn: Commit blocked by pre-commit hook (exit code 1) with output: svnlook: Can't write to stream: Broken pipe The following files contain tab characters: trunk/LayoutTests/ChangeLog Please use spaces instead to indent. If you must commit a file with tabs, use svn propset to set the allow-tabs property. Any chances someone is changing pre-commit hooks? And if yes, was this change intentional? No one has touched the pre-commit hook in a while. Are you sure you do not have tabs in your LayoutTests/ChangeLog? -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] svn stopped to commit into WebKit
Thanks a lot, William, probably that was the case although I did checked that before. Anyway, I managed to commit. yours, anton. On Thu, Apr 15, 2010 at 2:07 PM, William Siegrist wsiegr...@apple.com wrote: On Apr 15, 2010, at 6:54 AM, Anton Muhin wrote: Dear WebKitters, just a couple of moments ago svn stopped to commit into WebKit for me: svn: Commit blocked by pre-commit hook (exit code 1) with output: svnlook: Can't write to stream: Broken pipe The following files contain tab characters: trunk/LayoutTests/ChangeLog Please use spaces instead to indent. If you must commit a file with tabs, use svn propset to set the allow-tabs property. Any chances someone is changing pre-commit hooks? And if yes, was this change intentional? No one has touched the pre-commit hook in a while. Are you sure you do not have tabs in your LayoutTests/ChangeLog? -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit-patch and SVN
15.04.2010, в 00:37, Darin Fisher написал(а): If I need to work from the topmost directory, then I typically specify the directories I'm interested in on the svn command line (e.g., svn commit WebCore LayoutTests). That way the commands run faster. That's what I usually do, but I rarely pass the whole LayoutTests directory: prepare-ChangeLog WebCore LayoutTests/fast/dom svn ci WebCore LayoutTests/fast/dom LayoutTests/ChangeLog - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Qt is now a core builder
omg. The green (and orange) is blinding me:
build.webkit.org/waterfall?category=core.
Bill, I tend to rely on seeing the changes in the change column. It's not
the end of the world, but if it's not too hard to do, I'd appreciate
changing the svn hooks.
Ojan
On Thu, Apr 15, 2010 at 6:49 AM, William Siegrist wsiegr...@apple.comwrote:
One thing I noticed is that the Core-only waterfall does not show any
changes in the change column (because we're not sending them with any
specific category). If that bothers anyone, I can change the svn hooks. The
console does not have this problem.
-Bill
On Apr 15, 2010, at 6:22 AM, William Siegrist wrote:
The master has been reconfigured. Now there are two links, Core Console
and Core Waterfall on the main page which will show just the core builders.
The regular Console view also separates the builders by category, but will
show all of them.
-Bill
On Apr 14, 2010, at 9:17 AM, William Siegrist wrote:
I was thinking of something like the following, assuming we want to have
core builders still. The URL to see only core builders would be:
http://build.webkit.org/console?category=core
http://build.webkit.org/waterfall?category=core
... and we could use redirects or just add new links to the main page.
Index: master.cfg
===
--- master.cfg (revision 57518)
+++ master.cfg (working copy)
@@ -16,6 +16,8 @@
import re
import simplejson
+from webkitpy.common.net.buildbot import BuildBot as wkbuildbot
+
WithProperties = properties.WithProperties
class ConfigureBuild(buildstep.BuildStep):
@@ -369,6 +371,9 @@
config = simplejson.load(open('config.json'))
+# use webkitpy's buildbot module to test for core builders
+wkbb = wkbuildbot()
+
c['slaves'] = [BuildSlave(slave['name'], passwords[slave['name']],
max_builds=1) for slave in config['slaves']]
c['schedulers'] = []
@@ -397,6 +402,10 @@
builder[factory] = factory(*factoryArgs)
+builder[category] = noncore
+if wkbb._is_core_builder(builder['name']):
+builder[category] = core
+
c['builders'].append(builder)
loadBuilderConfig(c)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Implementing the sizes attribute of the link tag from HTML5
I would like to do it. See bug: https://bugs.webkit.org/show_bug.cgi?id=37674 Thoughts? - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing the sizes attribute of the link tag from HTML5
Do it. :DG On Thu, Apr 15, 2010 at 2:22 PM, Aaron Boodman a...@chromium.org wrote: I would like to do it. See bug: https://bugs.webkit.org/show_bug.cgi?id=37674 Thoughts? - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing the sizes attribute of the link tag from HTML5
On Apr 15, 2010, at 2:22 PM, Aaron Boodman wrote: I would like to do it. See bug: https://bugs.webkit.org/show_bug.cgi?id=37674 Thoughts? Seems like a good idea in general. More specifically, what would the implementation do? The bug explains the syntax, but not how it would affect WebKit's behavior. (It would be fine, perhaps preferable, to put that info in the bug). Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing the sizes attribute of the link tag from HTML5
On Thu, Apr 15, 2010 at 3:09 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 15, 2010, at 2:22 PM, Aaron Boodman wrote: I would like to do it. See bug: https://bugs.webkit.org/show_bug.cgi?id=37674 Thoughts? Seems like a good idea in general. More specifically, what would the implementation do? The bug explains the syntax, but not how it would affect WebKit's behavior. (It would be fine, perhaps preferable, to put that info in the bug). I'm not sure. I haven't looked at the existing implementation at all. I wanted to make sure there was general consensus before diving in. Once I have a proposed plan of attack, I will put it in the bug. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Qt is now a core builder
On Apr 15, 2010, at 8:59 AM, Ojan Vafai wrote: omg. The green (and orange) is blinding me: build.webkit.org/waterfall?category=core. Bill, I tend to rely on seeing the changes in the change column. It's not the end of the world, but if it's not too hard to do, I'd appreciate changing the svn hooks. I've updated the hooks, changes now show up on the waterfall again. -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing the sizes attribute of the link tag from HTML5
On Apr 15, 2010, at 3:14 PM, Aaron Boodman wrote: On Thu, Apr 15, 2010 at 3:09 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 15, 2010, at 2:22 PM, Aaron Boodman wrote: I would like to do it. See bug: https://bugs.webkit.org/show_bug.cgi?id=37674 Thoughts? Seems like a good idea in general. More specifically, what would the implementation do? The bug explains the syntax, but not how it would affect WebKit's behavior. (It would be fine, perhaps preferable, to put that info in the bug). I'm not sure. I haven't looked at the existing implementation at all. I wanted to make sure there was general consensus before diving in. Once I have a proposed plan of attack, I will put it in the bug. Well, it's hard to truly have consensus on adding feature without knowing what it is. That being said, I at least would love to see a more specific proposal for what we could do with link size. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing the sizes attribute of the link tag from HTML5
On Thu, Apr 15, 2010 at 3:25 PM, Maciej Stachowiak m...@apple.com wrote: Well, it's hard to truly have consensus on adding feature without knowing what it is. That being said, I at least would love to see a more specific proposal for what we could do with link size. I want to support bigger icons for the tabs in Chromium. I'm not sure what the path is for fetching favicons today. Does WebCore just implicitly do it, or does it expose the information to the host, who later may or may not make the request? I would like Chromium to be able to decide which icon to use from the list on a per-document basis, so if WebCore currently assumes that any favicon present should be loaded (or if that is configuration that is set at a pretty high level), I would want to change that as well. - a ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Clean way to allow delegates for PopupMenu?
Hello all,
I'm part of the EFL port team and we're implementing the PopupMenu,
however EFL is a different platform as for our port it is just a
state-full canvas, not relying on any widget set/toolkit, we do not
have the concept of a menu at all!
Looking at all existing implementations, they all go straight to
native platform menus. But we can't as we want to avoid such
dependencies. What we'd like to have is a delegate, that WebCore calls
the ChromeClient that is overloaded in WebKit, giving our View user a
callback with all data.
The good news is: we did it and it works quite well.
The bad news is: we cheated and include WebKit/efl/WebCoreSupport from
PopupMenuEfl.cpp, what a shame! (although some ports *cough qt*
include in WebCore defines from WebKit)
In order to have a clean design, we'd like to know the general opinion
on how to do it. From what I see Mac already defines a similar call in
ChromeClient.h:
#if PLATFORM(MAC)
...
virtual void willPopUpMenu(NSMenu *) { }
#endif
in our case, we'd need:
#if PLATFORM(EFL)
virtual void showPopupMenu(const IntRect rect, FrameView*
view, int index) { }
virtual void hidePopupMenu() { }
#endif
so our PopupMenuEfl.cpp will just proxy to these calls.
However, although Mac does that it may not be the best solution, so to
avoid endless patches to be discussed at bugzilla I'd like to know
your opinion on the best way so our patch is right from beginning.
Regards,
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [webkit meeting notes] build systems
On Wed, Apr 14, 2010 at 4:16 PM, Evan Martin e...@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
Re: [webkit-dev] [webkit meeting notes] build systems
Hi Evan, On Apr 14, 2010, at 5:16 PM, Evan Martin 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...) macxcode win vcproj qtqmake (cross-platform output) gtk autotools androidAndroid.mk (I heard rumors Android isn't actually upstream yet, though (?)) chromegyp (cross-platform output) haiku jam (?) brewwaf (?) wx uses waf, not sure about brew. derivative builds: rim hacked version of qt (qmake) efl qmake sonyautotools (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. [snip] 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 FWIW, for the wx build, I have waf calculate a list of sources to build by passing in a set of directories (also used for setting includes) and rules about feature defines and port info. So a sample rule list might be compile any source file in any of the following root directories, and also compile any source file in any wx and curl subdirectory, along with any source file in a cf subdirectory when building on Mac. Thanks to the highly structured nature of the WebKit build system, this works surprisingly well. Compiling a source file list (of even 1200+ files) actually adds almost no time to the build but has saved me many hours of patching build file lists and/or sharing that maintenance work with some other port. 90% of the build fixes I have to commit these days are new platform methods that need a port implementation (or at least a stub). Since waf is really just a Python API, this is all done in straight Python, and outside of the addition of new directories, I almost never need to update the build system, which is probably one reason most contributors hardly ever touch wx or notice it anymore, even though we're still out there chugging along at filling the implementation holes. ;-) Anyway, my $0.02 is that, in terms of immediate bang for the buck, we're probably better off trying to synchronize the build systems automatically in some way. My perception is that Qt developers will want to use qmake, GTK will want to use autotools, etc. and while some build systems could certainly be merged (e.g. as you say the Win and Mac projects for WebKit itself could be gyp-generated), I don't think we'll ever really narrow it down to one master system for a variety of reasons. I do, however, think we may be able to narrow the 'build system updating' process down to one step / one script that updates all ports simultaneously, and do so without too much effort. Since most build systems out there have their data stored in either XML or plain text, converting a build file list from one build system's data format to another is probably not more than a few hours of Python hacking, if that. I even long ago made a start on such an approach in WebKitTools/Scripts/update-sourc es-list.py, that used the old Bakefile XML to grab the list of common WebCore sources, but I bet it could be updated to pull from the .gyp file lists in no time. I really think someone should seriously consider investing some time and resources into improving this issue though, updating a build system doesn't take long but updating 7-10 build systems on almost a
Re: [webkit-dev] [webkit meeting notes] build systems
On Thu, Apr 15, 2010 at 9:15 PM, Kevin Ollivier kev...@theolliviers.comwrote: Anyway, my $0.02 is that, in terms of immediate bang for the buck, we're probably better off trying to synchronize the build systems automatically in some way. My perception is that Qt developers will want to use qmake, GTK will want to use autotools, etc. and while some build systems could certainly be merged (e.g. as you say the Win and Mac projects for WebKit itself could be gyp-generated), I don't think we'll ever really narrow it down to one master system for a variety of reasons. I do, however, think we may be able to narrow the 'build system updating' process down to one step / one script that updates all ports simultaneously, and do so without too much effort. If I'm not mistaking you, that seems to be the route Evan is discussing, with his concrete proposal being to investigate the feasibility of making gyp be the mechanism by which various different build systems can be generated from a single place (rather than seven). Or is this not what you were saying? Since most build systems out there have their data stored in either XML or plain text, converting a build file list from one build system's data format to another is probably not more than a few hours of Python hacking, if that. Indeed, we already have MSVC/XCode/makefile generators for gyp, I would assume that given those, a generator for e.g. qmake wouldn't be hard. I really think someone should seriously consider investing some time and resources into improving this issue though, updating a build system doesn't take long but updating 7-10 build systems on almost a daily basis probably adds up to some pretty significant amount of time and energy that could probably be spent on better things. I think that is the shared viewpoint that has led to this discussion. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
