Re: [webkit-dev] Loader diagram from yesterday's session
From: m...@apple.com Date: Sat, 17 Apr 2010 18:11:24 -0700 To: aba...@webkit.org CC: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Loader diagram from yesterday's session On Apr 17, 2010, at 5:22 PM, Adam Barth wrote: I took the liberty of cleaning up this diagram in sketchy: http://webblaze.org/abarth/webkit-loader.html If folks find this diagram useful, we can add it to the web site. Probably helpful for me- I was putting various statements into Loader to dump a list of secondary page resources- this worked fine on default debian build but didn't seem to do anything on the cygwin port. I'll have to look into Docloader as apparently this is an alt to Loader. Looks good, throw it on the wiki maybe? (You can include images on a wiki page by making them attachments first, that's what I did for the diagrams on ). Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev _ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1 ___ 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
2010/4/17 Kevin Ollivier kev...@theolliviers.com Hi Marc-Antoine, On Apr 17, 2010, at 11:26 AM, Marc-Antoine Ruel wrote: 2010/4/17 Kevin Ollivier kev...@theolliviers.com Hi Maciej, On Apr 16, 2010, at 3:34 PM, Maciej Stachowiak wrote: On Apr 16, 2010, at 8:09 AM, Nikolas Zimmermann wrote: Am 16.04.2010 um 16:44 schrieb Adam Treat: I am very skeptical that it is feasible to write a gyp generator that would output QMake files. There is a log of magic in those QMake files. My sense is that it would not be trivial by any means. Plus, I don't like the idea of a meta-meta generators. Seems way to mickey- mouse to me. Agreed to a certain degree. Using gyp/whatever to generate qmake files, to generate Makefile/Xcode files etc seems akward to me as well. What we really need to resolve is adding/removing files from compilation, that's the most common task that has to be done in 5+ build systems at the moment. Besides adding, removing and renaming, the other thing that's really hard is adding a new generated source rule. Although this is not needed as frequently, I think anyone adding a new code generator script that has to work across all WebKit ports would have a hellish time of it right now. If I had to do it myself, I would just skip any ports that don't use DerivedSources.make. So I have a new proposal: 1) Maintain a list of headers/source files to be compiled for ALL platforms (ie. dom/Node.cpp, etc..) 2) Keep all existing Makefile.am, WebCore.pro etc files as templates, ie. WebCore.pro.template, with a special variable somewhere marking the $$HEADER_LIST$$ and the $$SOURCE_LIST$$ 3) Use a script that generates individual build files (eg. WebCore.pro) from WebCore.pro.template, it only needs to insert the file list with the correct syntax in the correct places 4) Keep all platform specific files to be compiled in the individual build system files (eg. WebCore.pro.template) I think we'll never find a consensus on a single build system, there are too many different needs. I only care about the most repetitive work in order to keep the build system up2date: adding/removing cross-platform files. I think the proposal above does not handle the derived sources problem. It also doesn't handle files that are shared between multiple ports but not all ports. It also doesn't provide project files that are directly usable by IDEs, on platforms where that is the standard way to do development. Converting, say, a JSON list of files to some XML-based output format would not be difficult at all (and I Like this? http://trac.webkit.org/browser/trunk/WebCore/WebCore.gypi - It is currently not JSON compliant. It's in fact a python file but that can be fixed: s/'//g and removing the extra commas *should* be sufficient. - It is currently chromium specific, that's what I meant by de-chromification of the gyp files. It's mainly adding more stuff and fixing the regexp if I'm not mistaken. I don't mind if it doesn't become the golden file, the goal is just to hopefully reduce the number of build system, nothing more. Yes, precisely why I mentioned JSON and later gyp, though I don't know if Chromium-specific is the right word here. It even has wx port files in it, which I don't think are built by Chromium. :) I suppose you somehow filter out which ones Chromium should build after the fact? If so, where does that logic reside? mac, qt, gtk, wx, symbian and even some JSC files are listed. I'm 100% sure the lists aren't complete and I'll need to fix them along the way, especially JSC stuff which *is* a show stopper. .gypi files are header files. They can be imported by other .gypi or a .gyp file. Each .gyp file will generate a .sln, .xcodeproj, Makefile or SConstruct, depending on the selected build system. Each target inside a .gyp will generate a .vcproj or .scons. The regex logic lives in inside sources entries inside a target. You can have a list of file names, 'include' or 'exclude' with an array of regexp. Please take a look at the very bottom of this file for an example: http://trac.webkit.org/browser/trunk/WebCore/WebCore.gyp/WebCore.gyp The main gyp caveat is some of its shortcut notation like /, ! and +++. Please see the documentationhttp://code.google.com/p/gyp/wiki/InputFormatReferencefor more info if interested. WebCore.gyp already brings a lot of conditions which can make the whole thing messy as the number of platforms increases but these can be moved off individual .gypi files to keep the whole thing bearable. In the end, it may even not make sense to share the gyp files accross platform if they don't share enough build logic, it's no big deal as long as people can add and remove files easily. BTW, I don't why WebCore.gypihttp://trac.webkit.org/browser/trunk/WebCore/WebCore.gypilists the idl, svg idl, source files, webinspector and images as individual lists since they all have
[webkit-dev] GTK bots are now core builders
http://trac.webkit.org/changeset/57795 Sheriff Bot will nag you when you break GTK. Commit Queue will block while any GTK builder is broken. build.webkit.org will show GTK in the core set. [1] The GKT bots have been green every time I've looked the last 5 days. It would appear the WebKit community is keeping the GTK bots green, so I've updated the core builder list [2] to reflect reality. Thanks! If you've got questions, let me know. -eric 1. Thanks to _wms for this feature! Requires a buildbot server restart, should appear soon. 2. http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/common/net/buildbot.py#L310 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths
I wanted to add a couple comments and a question to this discussion. On Fri, Apr 16, 2010 at 2:54 PM, Maciej Stachowiak m...@apple.com wrote: I haven't contributed to WebKit's Python code yet, but I will say that I agree with Eric's sentiments here. 80-column limit is archaic and pointless. No one is developing WebKit on a vt220. Note that there are contexts where the limit does come into play that the user might not have as much control over, for example pasting into the body of an e-mail or into the comment box in bugs.webkit.org. Take a look at these two comments for example (which, incidentally, are about crash logs rather than code): https://bugs.webkit.org/show_bug.cgi?id=23558#c4 https://bugs.webkit.org/show_bug.cgi?id=36707#c1 So non-Python developers know, one argument for treating Python differently (aside from PEP8) is that the language supports a syntax for continuing lines to the next line that other languages don't (implied line continuation). Finally, just to clarify, which parts of PEP8 are we discussing ignoring? PEP8 has more specific guidelines for docstrings and how they should be formatted. For instance, it also contains this guideline in addition to the blanket 79-character limit: For flowing long blocks of text (docstrings or comments), limiting the length to 72 characters is recommended. --Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths
On Apr 18, 2010, at 12:33 PM, Chris Jerdonek wrote: I wanted to add a couple comments and a question to this discussion. On Fri, Apr 16, 2010 at 2:54 PM, Maciej Stachowiak m...@apple.com wrote: I haven't contributed to WebKit's Python code yet, but I will say that I agree with Eric's sentiments here. 80-column limit is archaic and pointless. No one is developing WebKit on a vt220. Note that there are contexts where the limit does come into play that the user might not have as much control over, for example pasting into the body of an e-mail or into the comment box in bugs.webkit.org. That reminds me, we should turn off the 80-column limit on bugs.webkit.org - there's no need for it to hard-wrap your text. That being said, we've lived for years with the fact that C++ code may get wrapped badly in these contexts and it hasn't really been an issue. Take a look at these two comments for example (which, incidentally, are about crash logs rather than code): https://bugs.webkit.org/show_bug.cgi?id=23558#c4 https://bugs.webkit.org/show_bug.cgi?id=36707#c1 So non-Python developers know, one argument for treating Python differently (aside from PEP8) is that the language supports a syntax for continuing lines to the next line that other languages don't (implied line continuation). Finally, just to clarify, which parts of PEP8 are we discussing ignoring? PEP8 has more specific guidelines for docstrings and how they should be formatted. For instance, it also contains this guideline in addition to the blanket 79-character limit: For flowing long blocks of text (docstrings or comments), limiting the length to 72 characters is recommended. I'm happy to let the people who hack on Python most decide whether a column limit is appropriate and if so which ones. Cheers, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
