Re: [webkit-dev] Buildsystem cleanup
Hi Patrick, On Apr 10, 2013, at 8:12 PM, Patrick Gansterer wrote: [snip] 1. There's also the Wx port, but they don't seem very interested in switching and it seems the build system is very low maintenance. There is still a patch at webkit.org/b/73100 for adding CMake files for Wx. The decision has already been made to remove wx from the tree (I need to whip up a patch when I have time…), so it probably isn't worth spending time on this. Regards, Kevin -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
level -- Chromium's Content layer or https://code.google.com/p/chromiumembedded/. Maybe one of those options are a better solution for a port like Wx with limited resources? Yes, in fact, that's an idea that has been stewing in my head a while now. It's mostly an issue of wxWebKit already being used in and working fine for a few projects, so there isn't a pressing need to deal with this issue right now, but I suspect when I need to start a new project, that will probably be the route I take. Part of the hesitation, though, is that I honestly find this project a lot of fun to hack on. :) By and large, I really do find this a great project and community to be a part of. Again, my apologies to you Kevin for my part in all this. You mean for helping me start this port in the first place, which was a godsend to me in the work I was and am doing, and has led to me learning a great deal over the years? Or, do you mean for getting the ball rolling that today leads me to have the other cross-platform WebKit options you mentioned, like Chromium and Qt, to choose from if I wanted to switch? Well... okay then, apology accepted. :) I've got some other comments to make, but I've got some stuff I need to get out the door, so there will probably be emails trickling out over the next couple days or so. I just felt compelled to respond to this message first, as I think in every instance you, and many others in the community, have really only tried to be helpful, and that is deeply appreciated. Please don't beat yourself up over that! Thanks, Kevin On Mon, Feb 11, 2013 at 7:44 PM, Benjamin Poulain benja...@webkit.org wrote: On Mon, Feb 11, 2013 at 6:17 PM, Kevin Ollivier kev...@theolliviers.com wrote: To be honest, I think I know more about the wx port, and would probably be better able to cleanly remove it from the tree, than you would. As I've said from the start, I'll remove it if that's what people want, but I do think the severity of this problem is being exaggerated, and going from posing the question of project status to giving a one week eviction notice in less than 24 hours seems a bit rash to say the least. I wish I could get paid good money to spend my time doing things like creating patches to remove inactive files from source trees. :) As it stands, though, this wasn't exactly on my TODO list for this week as of, say, this morning, and I do have plenty on it right now. I'm already even regretting how much time I've put into this discussion. I am sorry, I should have given more context. There is visibly a growing discontent in the community about the cost imposed from small ports. Just two weeks ago, there were 2 threads discussing the cost of peripheral ports. I am convinced a part of this is technical. The project has not changed its policies while the number of ports was growing. While duplicated code and interfaces was okay when there were only 3 ports, it has become a pain when we have 7+ ports to updates. This weekend, I was looking at technical ways to reduce the problems, and the wx port looks like one of the issue. Everyone with whom I have discussed that today seems to agree. You said yourself As things stand, I'd not only be okay with, but actually prefer, that no other port maintainers do anything to try and fix the wx build.. The best way to achieve that and reduce the maintenance for everyone is to have the wx port developed outside the tree. Which is why I propose to do the change. To think, it was wx and GTK that started the whole WebKit porting experiment in the first place, thanks to the gracious help of the WebKit community, and particularly Eric, and now I feel like the project can't push me out the door fast enough. ;-) Please be patient, I will take care of it, but I doubt I will manage it this week. In his email WebKit Wishes, Eric said It can’t be the job of the core maintainers to care about all the peripheral ports which contribute very little core code. I also think it is just not fair having hundred of peoples taking care of updating the port. There is no rush to move the port out of the tree. I suggested this week in order to have a definite timeline but there is no urgency. If there is interest in the wxWidgets community to make the port actively developed, that would be a great solution too. You do not have to do the change by yourself. I'd be happy to start if that helps you, and you can refine the changes. Cheers, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit
Re: [webkit-dev] Is the wxWidgets port maintained?
Hi Benjamin, On Feb 10, 2013, at 7:23 PM, Benjamin Poulain wrote: Hi again, While looking into DRT changes, I notice there is zero activity on the wxWidgets implementation. Looking at WebCore/WebKit, excluding general changes, the last commit for wxWidgets is 6 months old: http://trac.webkit.org/changeset/126457 So...is the port still active? Maybe it should live outside webkit.org like the Haiku port? The project is not dead per-se, but it's true that it's not very active these days. Recently, I haven't had a lot of time to devote to the port. The other big factor has been that I've been the only active contributor to the port pretty much since its inception, which has made patch submission pretty difficult due to the challenge of finding a reviewer with knowledge of the wx code. As a result, the wx activity on trunk will look pretty sparse since I'm making most of my changes on the wx port's git repo on gitorious.org rather than submitting patches for trunk. When it comes to trunk, I basically just periodically submit build fixes for any build breakages in order to merge and update my git mirror. I actually have recently been working on a patch to get trunk building again, though. The path of least resistance for me would simply be to ask people to ignore the wx port in their changes, but leave it in the tree. git is much better about these things, but I still remember what a pain it was to maintain the entire port in an svn branch back in the day, and I'd rather not re-try that experiment unless I really have to. If people feel strongly that I should approach things another way, though, I'm certainly open to ideas. Thanks, Kevin Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Feb 11, 2013, at 12:27 PM, Benjamin Poulain wrote: On Mon, Feb 11, 2013 at 11:27 AM, Kevin Ollivier kev...@theolliviers.com wrote: I actually have recently been working on a patch to get trunk building again, though. The path of least resistance for me would simply be to ask people to ignore the wx port in their changes, but leave it in the tree. git is much better about these things, but I still remember what a pain it was to maintain the entire port in an svn branch back in the day, and I'd rather not re-try that experiment unless I really have to. If people feel strongly that I should approach things another way, though, I'm certainly open to ideas. Asking people to ignore wx is basically the same as having the code outside the tree. Having the code outside the tree would make this change effective instead of having one more rule to the project. Looking at the history of wx's WebKit and platform code, the vast majority of changes are from Apple/Google. I think it is unfair to have many people maintain your code while you develop the project outside of the tree. Given the data, I am in favor of removing the wx port from webkit.org and have it be a separate tree on Gitorious or GitHub. What are the main pain points of developing outside webkit.org for you? Is there anything that can be done in the structure to simplify such changes? My big concern is not losing history while moving the wx files out of the tree and into a git branch, and also at the same time not losing the ability to merge the rest of trunk safely. Though I haven't investigated the process yet, so I don't know how easy or hard it may be. Thanks, Kevin Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
Hi Martin, On Feb 11, 2013, at 12:47 PM, Martin Robinson wrote: On Mon, Feb 11, 2013 at 11:27 AM, Kevin Ollivier kev...@theolliviers.com wrote: The project is not dead per-se, but it's true that it's not very active these days. Recently, I haven't had a lot of time to devote to the port. The other big factor has been that I've been the only active contributor to the port pretty much since its inception, which has made patch submission pretty difficult due to the challenge of finding a reviewer with knowledge of the wx code. As a result, the wx activity on trunk will look pretty sparse since I'm making most of my changes on the wx port's git repo on gitorious.org rather than submitting patches for trunk. When it comes to trunk, I basically just periodically submit build fixes for any build breakages in order to merge and update my git mirror. Regardless of whether the Wx port stays in the tree, I think you should consider changing your build system. I believe the only port that uses waf is Wx, so using cmake or gyp will make your work a lot easier. Actually, it will, if anything, increase the workload. Because I use waf, I am able to use Python to auto-generate the list of sources to build. In other words, I tell it to build all sources in a defined list of base source directories, along with all sources in baseDirectory/portName subdirs (where in this case I set portName to wx) and FileNameportName.cpp (e.g. FileNameWX.cpp if the port is wx), along with some additional similar rules for USE defines, like CF. Then if there are exceptions to these rules, I just filter them out of the results or explicitly add files when I need to, say if I need to compile a single Mac port source file. Since the WebKit tree is well-structured, this approach works quite well, with me having to define exceptions fairly rarely. The main issue I run into seems to be derived sources files that are no longer built / used but are still being generated. The performance hit of this is about 1 added second to my build, though on slower machines it might be a couple seconds. For me, it's negligible given the benefit I get from it. As an example, I'm still at the linking phase right now on Mac (dealing with the removal of the libWebKitLibrarySnowLeopard.a and a couple other things), but my patch so far to catch up with 6 months of changes in trunk is right now at 19KB, and about 30 lines or so of that is actually the build system changes. The number of exceptions I needed to add to the build over that time is 4, and I added about as many build directories to the list as well. I suspect if we were to accumulate the changes to cmake and gyp files over those 6 months, it will probably be well above 30-40 lines. Sure, I wouldn't have written all those lines myself, but sharing work with other developers is still more work for any individual developer than having the computer do the work for you. :) Everyone tells me how great cmake and gyp is, but I'm not sure any of them have taken any time out to actually investigate whether or not waf is as good as or better than their preferred tool. (It's not as good as auto-generating project files, but it's also in Python so integrating it with gyp would probably be a simple task.) I've often wanted to take some time out to get other ports building with it, as it probably would take a day or two at most, but I lack both the time and expertise in other ports to spend much time on that. Much of the code in there already is port-agnostic, with most wx-specific bits in a port_name == wx check, but of course there's the issue of the various port-specific build configurations and such for each port. Regards, Kevin --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Feb 11, 2013, at 2:13 PM, Brent Fulgham wrote: Hi Everyone, On Mon, Feb 11, 2013 at 1:51 PM, Ryosuke Niwa rn...@webkit.org wrote: Asking people to ignore wx is basically the same as having the code outside the tree. Having the code outside the tree would make this change effective instead of having one more rule to the project. My big concern is not losing history while moving the wx files out of the tree and into a git branch, and also at the same time not losing the ability to merge the rest of trunk safely. Though I haven't investigated the process yet, so I don't know how easy or hard it may be. I kindly ask you to let us remove it from trunk in that case. Given that we have 400+ contributors, having a port that's only maintained by a single person on trunk imposes a significant maintenance burden on others even if you said that people can break Wx port because not everyone reads this thread and wouldn't necessarily know your intent. I would be sad if the WebKit project started to exclude ports simply because they were (largely) maintained by a single person. I do agree that it's not fair to other ports if the primary developer is not working to keep the port building, but life happens and sometimes a lone developer cannot stay on top of the rapidly-changing source base. Having these ports in the main tree is a good thing, in my opinion, because it helps avoid fragmentation, and often the refactoring required to enable these ports provides architectural benefits to the project as a whole. FWIW, I think it'd be pretty simple to add a generic rule that if you want your port to benefit from shared maintenance, you must set up a build bot on the waterfall and/or an EWS bot. In fact, I personally think this ought to be a rule regardless of what happens to the wx port, as IMHO it's pretty much a pre-requisite for allowing people contributors on other ports to make changes to your code safely. Thanks, Kevin -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Feb 11, 2013, at 2:01 PM, Martin Robinson wrote: On Mon, Feb 11, 2013 at 1:41 PM, Kevin Ollivier kev...@theolliviers.com wrote: Actually, it will, if anything, increase the workload. Because I use waf, I am able to use Python to auto-generate the list of sources to build. In other words, I tell it to build all sources in a defined list of base source directories, along with all sources in baseDirectory/portName subdirs (where in this case I set portName to wx) and FileNameportName.cpp (e.g. FileNameWX.cpp if the port is wx), along with some additional similar rules for USE defines, like CF. Then if there are exceptions to these rules, I just filter them out of the results or explicitly add files when I need to, say if I need to compile a single Mac port source file. Since the WebKit tree is well-structured, this approach works quite well, with me having to define exceptions fairly rarely. The main issue I run into seems to be derived sources files that are no longer built / used but are still being generated. The performance hit of this is about 1 added second to my build, though on slower machin es it might be a couple seconds. For me, it's negligible given the benefit I get from it. If I understand correctly, gyp is also capable of this kind of wildcard inclusion and exclusion. This will be the tool that allows the gyp build to be shared among many ports with the same source lists. Yes, but that is not what I see when I check, say, Source/WebCore/WebCore.gypi. Which, BTW, has had around 500 revisions in it over the past 6 months in comparison to the ~10 lines of changes to source files in my patch-in-progress. So while gyp itself might have that feature in it, for whatever reason, the WebKit projects do not utilize that feature right now, so in practice, a switch to gyp means a switch away from rule-based compilation. Plus, my overarching reason for switching away from a tool like gyp or bakefile was to get away from using domain-specific languages for build tools. In short, waf doesn't have a syntax, it has an API. With waf and Python, I don't have to worry about fitting my design goals into some project file format built perhaps by someone with a different set of needs than mine. If I need it, I just code it. On-demand automated dependency download is one example of this. Another thing on my TODO list, actually, is to integrate in a little tool I have started coding up called 'gattai', http://sf.net/projects/gattai, which aims to be able to pull and, if necessary, build the various deps a project needs in source or binary form. And yet another thing I wanted to play with actually was having it dynamically generate AllInOne.cpp files for various directories and profile how much of a speed change there is in the builds by doing so. I suspect that we could squeeze out some considerable gains that way. Anyway, those are just some examples. Just wanted to say that for me, the rule-based compilation is certainly one of the most used features of waf, but it's far from the only thing I chose it for. The situation we have now is that we have many build systems, so we probably need to think about discarding some awesome ones [1] for ones that are popular with our peers. If the Wx port were to move out of the tree, obviously this isn't a huge deal -- just a suggestion. 1. All things being equal, waf looks to be the best replacement for autotools for WebKitGTK+. I've heard it's faster than both scons and cmake and it supports 'make install' and 'make dist.' Sadly, not all things are equal at svn.webkit.org, so gyp or cmake are the best hope at the moment. Yes, it's light years faster than Scons, and I don't know about cmake but honestly, I have a hard time thinking my build could get much faster than waf makes it, aside from speeding up the compiler itself. Efficient use of multiple cores, and smart dependency tracking both help considerably. Anyway, I do understand your point about adoption, and it's the primary reason I don't really say much on the issue. I think waf has a lot of things going for it, some of which I feel are pretty well-suited to a project like WebKit, but if people already have their minds set on other tools, that's pretty much the end of the conversation. Thanks, Kevin --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Feb 11, 2013, at 3:33 PM, Dirk Pranke wrote: On Mon, Feb 11, 2013 at 3:26 PM, Kevin Ollivier kev...@theolliviers.com wrote: On Feb 11, 2013, at 2:01 PM, Martin Robinson wrote: On Mon, Feb 11, 2013 at 1:41 PM, Kevin Ollivier kev...@theolliviers.com wrote: Actually, it will, if anything, increase the workload. Because I use waf, I am able to use Python to auto-generate the list of sources to build. In other words, I tell it to build all sources in a defined list of base source directories, along with all sources in baseDirectory/portName subdirs (where in this case I set portName to wx) and FileNameportName.cpp (e.g. FileNameWX.cpp if the port is wx), along with some additional similar rules for USE defines, like CF. Then if there are exceptions to these rules, I just filter them out of the results or explicitly add files when I need to, say if I need to compile a single Mac port source file. Since the WebKit tree is well-structured, this approach works quite well, with me having to define exceptions fairly rarely. The main issue I run into seems to be derived sources files that are no longer built / used but are still being generated. The performance hit of this is about 1 added second to my build, though on slower mach in es it might be a couple seconds. For me, it's negligible given the benefit I get from it. If I understand correctly, gyp is also capable of this kind of wildcard inclusion and exclusion. This will be the tool that allows the gyp build to be shared among many ports with the same source lists. Yes, but that is not what I see when I check, say, Source/WebCore/WebCore.gypi. Which, BTW, has had around 500 revisions in it over the past 6 months in comparison to the ~10 lines of changes to source files in my patch-in-progress. So while gyp itself might have that feature in it, for whatever reason, the WebKit projects do not utilize that feature right now, so in practice, a switch to gyp means a switch away from rule-based compilation. There's two different things going on here: ease of maintenance, and reproducibility. Using wildcards in the (meta-)build file itself can make things easier but make it harder to get reproducible builds since you might accidentally include files in the tree you didn't want. When you're on a minority port, having wildcards certainly makes your life easier because you don't have to track every change we make explicitly, and it's probably easier for you to ensure you're doing things correctly in your own checkouts, so you don't have to worry about reproducibility as much. If the filesystem always follows clearly defined rules, then I'd argue that reproducibility would not be an issue, though. WebKit currently doesn't always, but the vast majority of times it does. The cases where it doesn't are few and far between, and I don't think fixes would be all that difficult. You can always create specific locations, like perhaps a Shared directory, for any special cases that should explicitly be added by more than one, but a subset of, ports, and can't be properly encapsulated into a feature or use define. (For example, the WhateverNone.cpp are one of the special exceptions I have to account for, and they could go in there.) I think the concern is really that this approach seems 'implicit' rather than 'explicit'. With clear filesystem rules, though, it's not actually implicit. A file going into one of the directories listed as a primary build dir means it is to be built by all ports. So long as the project defines said rules, the act of putting it there is explicit, and expresses intent. This also, BTW, addresses the problem of old stuff being left in the tree. To remove it from the build, you have to remove it, so you can just leave it sitting in the tree for someone to stumble across later. (I'm pretty sure a number of the exceptions I define in waf are actually examples of this.) On the other hand, if you were to convert to using the same gypi files we were using, then you wouldn't have to track every change we make, either; you'd get them for free. Yes, but this mechanism relies on WebKit's policies about fixing others' build systems to be effective. waf, on the other hand, removes that task almost entirely. Plus, see my other comments about all the other benefits of using a meta-build system. (And BTW, on that topic, in newer versions of waf there is even a build system kit that provides a starting point for building your own build system off of waf. :) Thanks, Kevin -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Feb 11, 2013, at 3:37 PM, Ryosuke Niwa wrote: On Mon, Feb 11, 2013 at 3:26 PM, Kevin Ollivier kev...@theolliviers.com wrote: On Feb 11, 2013, at 2:01 PM, Martin Robinson wrote: On Mon, Feb 11, 2013 at 1:41 PM, Kevin Ollivier kev...@theolliviers.com wrote: Actually, it will, if anything, increase the workload. Because I use waf, I am able to use Python to auto-generate the list of sources to build. In other words, I tell it to build all sources in a defined list of base source directories, along with all sources in baseDirectory/portName subdirs (where in this case I set portName to wx) and FileNameportName.cpp (e.g. FileNameWX.cpp if the port is wx), along with some additional similar rules for USE defines, like CF. Then if there are exceptions to these rules, I just filter them out of the results or explicitly add files when I need to, say if I need to compile a single Mac port source file. Since the WebKit tree is well-structured, this approach works quite well, with me having to define exceptions fairly rarely. The main issue I run into seems to be derived sources files that are no longer built / used but are still being generated. The performance hit of this is about 1 added second to my build, though on slower machin es it might be a couple seconds. For me, it's negligible given the benefit I get from it. If I understand correctly, gyp is also capable of this kind of wildcard inclusion and exclusion. This will be the tool that allows the gyp build to be shared among many ports with the same source lists. Yes, but that is not what I see when I check, say, Source/WebCore/WebCore.gypi. Which, BTW, has had around 500 revisions in it over the past 6 months in comparison to the ~10 lines of changes to source files in my patch-in-progress. So while gyp itself might have that feature in it, for whatever reason, the WebKit projects do not utilize that feature right now, so in practice, a switch to gyp means a switch away from rule-based compilation. We do! WebCore.gypi just lists all files and http://trac.webkit.org/browser/trunk/Source/WebCore/WebCore.gyp/WebCore.gyp defines what gets built on each platform. Sorry if I wasn't clear, but by rule-based compilation, I mean not having a WebCore.gypi to maintain at all. waf needs no such file because it checks the filesystem with a set of rules to determine what sources to build. Thanks, Kevin - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
On Feb 11, 2013, at 5:03 PM, Dirk Pranke wrote: On Mon, Feb 11, 2013 at 4:30 PM, Kevin Ollivier kev...@theolliviers.com wrote: On Feb 11, 2013, at 3:33 PM, Dirk Pranke wrote: On Mon, Feb 11, 2013 at 3:26 PM, Kevin Ollivier kev...@theolliviers.com wrote: On Feb 11, 2013, at 2:01 PM, Martin Robinson wrote: On Mon, Feb 11, 2013 at 1:41 PM, Kevin Ollivier kev...@theolliviers.com wrote: Actually, it will, if anything, increase the workload. Because I use waf, I am able to use Python to auto-generate the list of sources to build. In other words, I tell it to build all sources in a defined list of base source directories, along with all sources in baseDirectory/portName subdirs (where in this case I set portName to wx) and FileNameportName.cpp (e.g. FileNameWX.cpp if the port is wx), along with some additional similar rules for USE defines, like CF. Then if there are exceptions to these rules, I just filter them out of the results or explicitly add files when I need to, say if I need to compile a single Mac port source file. Since the WebKit tree is well-structured, this approach works quite well, with me having to define exceptions fairly rarely. The main issue I run into seems to be derived sources files that are no longer built / used but are still being generated. The performance hit of this is about 1 added second to my build, though on slower ma chin es it might be a couple seconds. For me, it's negligible given the benefit I get from it. If I understand correctly, gyp is also capable of this kind of wildcard inclusion and exclusion. This will be the tool that allows the gyp build to be shared among many ports with the same source lists. Yes, but that is not what I see when I check, say, Source/WebCore/WebCore.gypi. Which, BTW, has had around 500 revisions in it over the past 6 months in comparison to the ~10 lines of changes to source files in my patch-in-progress. So while gyp itself might have that feature in it, for whatever reason, the WebKit projects do not utilize that feature right now, so in practice, a switch to gyp means a switch away from rule-based compilation. There's two different things going on here: ease of maintenance, and reproducibility. Using wildcards in the (meta-)build file itself can make things easier but make it harder to get reproducible builds since you might accidentally include files in the tree you didn't want. When you're on a minority port, having wildcards certainly makes your life easier because you don't have to track every change we make explicitly, and it's probably easier for you to ensure you're doing things correctly in your own checkouts, so you don't have to worry about reproducibility as much. If the filesystem always follows clearly defined rules, then I'd argue that reproducibility would not be an issue, though. WebKit currently doesn't always, but the vast majority of times it does. The cases where it doesn't are few and far between, and I don't think fixes would be all that difficult. You can always create specific locations, like perhaps a Shared directory, for any special cases that should explicitly be added by more than one, but a subset of, ports, and can't be properly encapsulated into a feature or use define. (For example, the WhateverNone.cpp are one of the special exceptions I have to account for, and they could go in there.) I think the concern is really that this approach seems 'implicit' rather than 'explicit'. With clear filesystem rules, though, it's not actually implicit. A file going into one of the directories listed as a primary build dir means it is to be built by all ports. So long as the project defines said rules, the act of putting it there is explicit, and expresses intent. This also, BTW, addresses the problem of old stuff being left in the tree. To remove it from the build, you have to remove it, so you can just leave it sitting in the tree for someone to stumble across later. (I'm pretty sure a number of the exceptions I define in waf are actually examples of this.) I'm not sure we're talking about the same sort of concerns. The case I'm talking about when you have a makefile that says something like SRCS=*.cpp. Then, I have to remember to save a local copy of a file as foo.cpp.orig rather than foo_orig.cpp, and if I want to rename a file I have to actually rename it rather than copy it (or at least remember to delete it). I think you're talking more about conventions over which directories contain files for each port? Yes, that was what I was talking about. I tend to avoid making copies of files like what you describe so as not to clutter my local tree. If I'm going to make substantial or more experimental changes, I just move it onto a git branch so I can just wipe everything if it doesn't pan out. On the other hand, if you were to convert to using the same gypi files we were
Re: [webkit-dev] Is the wxWidgets port maintained?
On Feb 11, 2013, at 5:20 PM, Benjamin Poulain wrote: On Mon, Feb 11, 2013 at 5:11 PM, Ryosuke Niwa rn...@webkit.org wrote: On Mon, Feb 11, 2013 at 4:53 PM, Kevin Ollivier kev...@theolliviers.com wrote: I know you're speaking more in general here, but just to be clear, over the past 6 months, the data hit that WebKit engineers have taken on account of the wx port is close to 0 bytes. The only time svn up or git fetch has pulled anything related to wx is when other developers attempted to update the wx port based on changes made to common code. As things stand, I'd not only be okay with, but actually prefer, that no other port maintainers do anything to try and fix the wx build. This way the port is not causing anyone else a burden except occasionally when I do land some fixes. As I said in my reply to Brent, I think a no build bot / no shared maintenance project rule is not only reasonable, as a practical matter it is required. I'd argue that others contributors having to know to ignore Wx port's code is the most significant cost. How is a new contributor supposed to know to ignore Wx port code? It looks like everyone agree wx would be better maintained outside webkit.org. Kevin just need to find a technical solution to the problem of maintaining the history. I will make a patch removing wxWidgets from the tree. Kevin, can you communicate when you are ready for the transition? I'd like to do that this week if that is okay with you. To be honest, I think I know more about the wx port, and would probably be better able to cleanly remove it from the tree, than you would. As I've said from the start, I'll remove it if that's what people want, but I do think the severity of this problem is being exaggerated, and going from posing the question of project status to giving a one week eviction notice in less than 24 hours seems a bit rash to say the least. I wish I could get paid good money to spend my time doing things like creating patches to remove inactive files from source trees. :) As it stands, though, this wasn't exactly on my TODO list for this week as of, say, this morning, and I do have plenty on it right now. I'm already even regretting how much time I've put into this discussion. To think, it was wx and GTK that started the whole WebKit porting experiment in the first place, thanks to the gracious help of the WebKit community, and particularly Eric, and now I feel like the project can't push me out the door fast enough. ;-) Please be patient, I will take care of it, but I doubt I will manage it this week. Regards, Kevin Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore (revisited)
Hi Darin, On Nov 2, 2011, at 4:42 PM, Darin Adler wrote: On Nov 2, 2011, at 4:09 PM, Mark Rowe wrote: There are a few related goals here that I'm aware of: a) Separate WTF out of JavaScriptCore since it doesn't logically belong there, but was simply a convenient home for it. b) Separate WebCore/platform out of WebCore to help avoid layering violations. c) Rework the Mac build process so that we can eliminate forwarding headers and remove the duplication of .xcconfig files. The process for addressing a) and b) will be similar: 1) Move the relevant code from its current location to the new location. 2) Create a new Xcode project that builds the desired output in the appropriate fashion. Update other build systems as is applicable. 3) Apple starts including the new project in our build process. Step (2) here involves coming up with a good solution for export control in both the WTF and platform cases. Today we use an explicit .exp file for JavaScriptCore and WebCore on Mac and I believe a .def file in the Apple Windows WebKit port. So there might be a necessary first step of moving to a different export approach. And I know someone has been working on that. If you guys want to go the route of finishing up the export macros work, let me know and I'll see what I can do. I probably can't devote a lot of time to it for the next week or two, but I'd like to see this fixed regardless of if it's used to move forward the WTF split, obviously, so I can put a higher priority on it if I know there are reviewers waiting to land things. :) FWIW, I did distinguish between JS and WTF symbol export macros in the work I've been doing, so the macros approach will support the split as-is. Thanks, Kevin -- Darin ___ 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] Moving WTF out of JavaScriptCore (revisited)
Hi Mark, On Nov 4, 2011, at 10:59 AM, Mark Rowe wrote: On 2011-11-04, at 10:57, Kevin Ollivier wrote: Hi Steve, On Nov 4, 2011, at 9:12 AM, Steve Falkenburg wrote: On Nov 4, 2011, at 8:48 AM, Kevin Ollivier wrote: Step (2) here involves coming up with a good solution for export control in both the WTF and platform cases. Today we use an explicit .exp file for JavaScriptCore and WebCore on Mac and I believe a .def file in the Apple Windows WebKit port. So there might be a necessary first step of moving to a different export approach. And I know someone has been working on that. If you guys want to go the route of finishing up the export macros work, let me know and I'll see what I can do. I probably can't devote a lot of time to it for the next week or two, but I'd like to see this fixed regardless of if it's used to move forward the WTF split, obviously, so I can put a higher priority on it if I know there are reviewers waiting to land things. :) FWIW, I did distinguish between JS and WTF symbol export macros in the work I've been doing, so the macros approach will support the split as-is. If WTF is to be a static library, there's no need to change anything in the .def file on Windows. .def files apply only to DLLs. Yes, I know, just saying I'd be willing to help if they wanted to go the DLL route. Making it static would make life easier for me also by allowing us to remove the need for WTF symbol exports entirely, of course, so either way is a plus for me. WTF being a static library doesn't change anything with respect to exports. It will still only be linked by a single dynamic library, and that library will be expected to export the necessary symbols for other clients. Doing otherwise would cause problems due to multiple instances of WTF's data being created (e.g., separate FastMalloc heaps for each library that linked directly to WTF). So I'm assuming that dynamic library would be JSCore, then? Is the idea basically just to have a clean separation between WTF and JSCore build projects? Thanks, Kevin - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why is gtest in the Source directory?
On May 12, 2011, at 11:48 AM, Darin Adler wrote: On May 12, 2011, at 11:33 AM, David Levin wrote: Layout/ # Would be nice to have a better name since these test much more than Layout DumpRenderTreeTests? Integration? AutomatedHtmlTests? Here are some characteristics of these tests that may help us name the directory: 1) This is the primary suite of WebKit tests. 2) These tests are all automated. 3) These tests all include an expected result (broadly including future addition of reftests). 4) These tests are regression tests; most are designed to catch any changes in behavior, not just detect failure. 5) These tests consist of HTML or SVG markup, with CSS and JavaScript, much like webpages in the wild. 6) Most of these tests can also be run by opening them in a web browser. 7) Most of these tests are designed to test end-to-end, although some are more like unit tests. I don’t think they should be named after DumpRenderTree because that name is itself a misnomer. I think that (7) above does fit with the name Integration, but that name still doesn’t work so well for me. Despite (5) above I don’t love the idea of having HTML in the name when we can accommodate SVG tests too. What about just Web, Engine or WebPages? If SVG complicates the naming issue, maybe it could be moved to its own top level directory? That would avoid any confusion over where one would expect to find the SVG tests. Kevin -- Darin ___ 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] What's up with the Chromium EWS bots?
Hi all, I've got a patch that has been waiting in the queue for over a day now, and it's still in position #6 for cr-linux and #7 for cr-mac. The position has changed over that time, so it seems the bots are processing patches, but they're going incredibly slowly. All the other bots finished processing the patch about a day and a half ago. Anyone know what's up? Thanks, Kevin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] What's up with the Chromium EWS bots?
Thanks for looking into this! Just let me know if I need to re-submit the patch or anything after the bots are fixed. Kevin On Mar 9, 2011, at 9:16 AM, Eric Seidel wrote: I'm told the Skia repository was rebuilt from scratch. We'll need to remove the skia directory on these bots to let them check it out again: http://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thread/e4cb6956c9ef0b39?pli=1 On Wed, Mar 9, 2011 at 11:12 AM, Eric Seidel e...@webkit.org wrote: Looks like the cr-linux bots svn checkout got corrupted. Adam has access and can rebuild it: http://queues.webkit.org/results/8110874 The cr-mac bot looks like it's having similar trouble: http://queues.webkit.org/results/8118430 I can look at rebuildign that one. I wonder what went wrong with chromium's svn repository to cause this? Those bots are in different data centers, in different states, owned by different companies and running different OSes! So I suspect something changed on src.chromium.org. -eric On Wed, Mar 9, 2011 at 10:08 AM, Kevin Ollivier kev...@theolliviers.com wrote: Hi all, I've got a patch that has been waiting in the queue for over a day now, and it's still in position #6 for cr-linux and #7 for cr-mac. The position has changed over that time, so it seems the bots are processing patches, but they're going incredibly slowly. All the other bots finished processing the patch about a day and a half ago. Anyone know what's up? Thanks, Kevin ___ 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] Moving WTF out of JavaScriptCore
On Feb 9, 2011, at 2:08 PM, Mark Rowe wrote: On 2011-02-09, at 14:05, Adam Barth wrote: On Wed, Feb 9, 2011 at 1:30 PM, Mark Rowe mr...@apple.com wrote: On 2011-02-09, at 13:06, Adam Barth wrote: On Thu, Dec 23, 2010 at 1:32 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 22, 2010, at 12:06 PM, Adam Barth wrote: On Wed, Dec 22, 2010 at 10:40 AM, Mark Rowe mr...@apple.com wrote: On 2010-12-22, at 10:34, Adam Barth wrote: As an aside, would creating the Sources directory make it easier to move WTF out of JavaScriptCore? I don't think that the location of the source on disk is a big factor in WTF's presence in JavaScriptCore. Oh, I thought the main involved in creating a new top-level source directory was the main thing causing WTF to live inside JavaScriptCore. I know we've talked about moving it out of JavaScriptCore for a while now. Is that just a matter of someone (e.g., me) doing the work or are there other limiting factors? If we switch to a top-level Sources directory, and on the Apple-internal side switch to submitting WebKit to the OS build using this single top-level sources directory, then it's easy to make new top-level directories without disrupting anything. If we don't do the above, we'd have to set things up so we can submit WTF separately to the build to cope, and we'd need to make it build a static library and install private headers. So I think it is easier to make this change if we do the Sources/ change first. Now that we've moved all the source code into Source, I'd like to try moving WTF out of JavaScriptCore. Is there anything on the Apple-internal side that needs to happen first? Maciej's response above mentions that we need to make some internal process changes before it's easy to add new top-level projects without disrupting things. Unless there's some urgent reason to move WTF I'd prefer that you hold off on doing this. Would it make sense to set a target date in the future for making these internal changes? I'm certainly not in a rush, but I'd also like to make progress on this at some point. I don't think that would be useful. The changes that block this are the same changes that prevent us from removing the concept of forwarding headers. We're as interested as you are in seeing them done. I'm also very interested in seeing this done, as it affects the wx port too, and I know from trying to make header changes to WTF (and watching all the breakages) that almost all ports have hacks along the lines of forwarding headers that deal with the issue of WTF being a separate project in theory, but a private implementation detail of JSC in practice. Pulling WTF out of JSC would, I think, go a long way to undoing a lot of those hacks and reducing the time and maintenance cost of making changes to WTF. Is the problem here that these internal changes are very difficult and/or time consuming to implement? I wish I could help somehow because I'd much rather spend time trying to fix this problem the right way and for good than spending that time sorting out all the build breakages every time I try to do something like add a new header to WTF that I want to be widely available among ports and projects in WebKit. Kevin - Mark ___ 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] Moving WTF out of JavaScriptCore
On Feb 9, 2011, at 3:11 PM, Mark Rowe wrote: On 2011-02-09, at 14:51, Kevin Ollivier wrote: On Feb 9, 2011, at 2:08 PM, Mark Rowe wrote: On 2011-02-09, at 14:05, Adam Barth wrote: On Wed, Feb 9, 2011 at 1:30 PM, Mark Rowe mr...@apple.com wrote: On 2011-02-09, at 13:06, Adam Barth wrote: On Thu, Dec 23, 2010 at 1:32 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 22, 2010, at 12:06 PM, Adam Barth wrote: On Wed, Dec 22, 2010 at 10:40 AM, Mark Rowe mr...@apple.com wrote: On 2010-12-22, at 10:34, Adam Barth wrote: As an aside, would creating the Sources directory make it easier to move WTF out of JavaScriptCore? I don't think that the location of the source on disk is a big factor in WTF's presence in JavaScriptCore. Oh, I thought the main involved in creating a new top-level source directory was the main thing causing WTF to live inside JavaScriptCore. I know we've talked about moving it out of JavaScriptCore for a while now. Is that just a matter of someone (e.g., me) doing the work or are there other limiting factors? If we switch to a top-level Sources directory, and on the Apple-internal side switch to submitting WebKit to the OS build using this single top-level sources directory, then it's easy to make new top-level directories without disrupting anything. If we don't do the above, we'd have to set things up so we can submit WTF separately to the build to cope, and we'd need to make it build a static library and install private headers. So I think it is easier to make this change if we do the Sources/ change first. Now that we've moved all the source code into Source, I'd like to try moving WTF out of JavaScriptCore. Is there anything on the Apple-internal side that needs to happen first? Maciej's response above mentions that we need to make some internal process changes before it's easy to add new top-level projects without disrupting things. Unless there's some urgent reason to move WTF I'd prefer that you hold off on doing this. Would it make sense to set a target date in the future for making these internal changes? I'm certainly not in a rush, but I'd also like to make progress on this at some point. I don't think that would be useful. The changes that block this are the same changes that prevent us from removing the concept of forwarding headers. We're as interested as you are in seeing them done. I'm also very interested in seeing this done, as it affects the wx port too, and I know from trying to make header changes to WTF (and watching all the breakages) that almost all ports have hacks along the lines of forwarding headers that deal with the issue of WTF being a separate project in theory, but a private implementation detail of JSC in practice. Pulling WTF out of JSC would, I think, go a long way to undoing a lot of those hacks and reducing the time and maintenance cost of making changes to WTF. As far as I'm aware only the Mac and Windows ports have anything along the lines of forwarding headers. No other port that I'm aware of needs anything similar. Is the problem here that these internal changes are very difficult and/or time consuming to implement? I wish I could help somehow because I'd much rather spend time trying to fix this problem the right way and for good than spending that time sorting out all the build breakages every time I try to do something like add a new header to WTF that I want to be widely available among ports and projects in WebKit. If you can point me at changes where you've had issues with forwarding headers I can provide suggestions as to how you can avoid problems with them in the future. A quick look through SVN history doesn't reveal any changes related to forwarding headers from you. Actually, I'm referring to what is still an open bug. (https://bugs.webkit.org/show_bug.cgi?id=27551) The issue in question is a change to try and move the definition of JSC / WTF export symbols into the headers rather than using the current export definition files. Resolving this issue is a pre-requisite for wx DRT support, and also blocks a bug related to defining export macros for C++ DOM bindings as well. Part of what fixing this bug entailed was adding a new header to WTF, I called it wtf/ExportMacros.h, which defined WTF_EXPORT and WTF_IMPORT so we could consolidate the export symbol attribute definition macros into one place in the tree, instead of copying and pasting the same logic (just with different XYZ_EXPORT and IMPORT names) into every config.h file. However, when I tried adding the WTF header, almost every port failed with some error, and it often had to do with header availability issues. (e.g. WebCore has access to this WTF header, but WebKit, or DRT, or JSC.exe doesn't, and won't unless you add it to some copied / forwarded header list). FWIW, I did get around to fixing most of the ports, but the reason
Re: [webkit-dev] Moving WTF out of JavaScriptCore
On Feb 9, 2011, at 4:28 PM, Mark Rowe wrote: On 2011-02-09, at 16:21, Kevin Ollivier wrote: On Feb 9, 2011, at 3:11 PM, Mark Rowe wrote: On 2011-02-09, at 14:51, Kevin Ollivier wrote: On Feb 9, 2011, at 2:08 PM, Mark Rowe wrote: On 2011-02-09, at 14:05, Adam Barth wrote: On Wed, Feb 9, 2011 at 1:30 PM, Mark Rowe mr...@apple.com wrote: On 2011-02-09, at 13:06, Adam Barth wrote: On Thu, Dec 23, 2010 at 1:32 PM, Maciej Stachowiak m...@apple.com wrote: On Dec 22, 2010, at 12:06 PM, Adam Barth wrote: On Wed, Dec 22, 2010 at 10:40 AM, Mark Rowe mr...@apple.com wrote: On 2010-12-22, at 10:34, Adam Barth wrote: As an aside, would creating the Sources directory make it easier to move WTF out of JavaScriptCore? I don't think that the location of the source on disk is a big factor in WTF's presence in JavaScriptCore. Oh, I thought the main involved in creating a new top-level source directory was the main thing causing WTF to live inside JavaScriptCore. I know we've talked about moving it out of JavaScriptCore for a while now. Is that just a matter of someone (e.g., me) doing the work or are there other limiting factors? If we switch to a top-level Sources directory, and on the Apple-internal side switch to submitting WebKit to the OS build using this single top-level sources directory, then it's easy to make new top-level directories without disrupting anything. If we don't do the above, we'd have to set things up so we can submit WTF separately to the build to cope, and we'd need to make it build a static library and install private headers. So I think it is easier to make this change if we do the Sources/ change first. Now that we've moved all the source code into Source, I'd like to try moving WTF out of JavaScriptCore. Is there anything on the Apple-internal side that needs to happen first? Maciej's response above mentions that we need to make some internal process changes before it's easy to add new top-level projects without disrupting things. Unless there's some urgent reason to move WTF I'd prefer that you hold off on doing this. Would it make sense to set a target date in the future for making these internal changes? I'm certainly not in a rush, but I'd also like to make progress on this at some point. I don't think that would be useful. The changes that block this are the same changes that prevent us from removing the concept of forwarding headers. We're as interested as you are in seeing them done. I'm also very interested in seeing this done, as it affects the wx port too, and I know from trying to make header changes to WTF (and watching all the breakages) that almost all ports have hacks along the lines of forwarding headers that deal with the issue of WTF being a separate project in theory, but a private implementation detail of JSC in practice. Pulling WTF out of JSC would, I think, go a long way to undoing a lot of those hacks and reducing the time and maintenance cost of making changes to WTF. As far as I'm aware only the Mac and Windows ports have anything along the lines of forwarding headers. No other port that I'm aware of needs anything similar. Is the problem here that these internal changes are very difficult and/or time consuming to implement? I wish I could help somehow because I'd much rather spend time trying to fix this problem the right way and for good than spending that time sorting out all the build breakages every time I try to do something like add a new header to WTF that I want to be widely available among ports and projects in WebKit. If you can point me at changes where you've had issues with forwarding headers I can provide suggestions as to how you can avoid problems with them in the future. A quick look through SVN history doesn't reveal any changes related to forwarding headers from you. Actually, I'm referring to what is still an open bug. (https://bugs.webkit.org/show_bug.cgi?id=27551) The issue in question is a change to try and move the definition of JSC / WTF export symbols into the headers rather than using the current export definition files. Resolving this issue is a pre-requisite for wx DRT support, and also blocks a bug related to defining export macros for C++ DOM bindings as well. Part of what fixing this bug entailed was adding a new header to WTF, I called it wtf/ExportMacros.h, which defined WTF_EXPORT and WTF_IMPORT so we could consolidate the export symbol attribute definition macros into one place in the tree, instead of copying and pasting the same logic (just with different XYZ_EXPORT and IMPORT names) into every config.h file. However, when I tried adding the WTF header, almost every port failed with some error, and it often had to do with header availability issues. (e.g. WebCore has access to this WTF header, but WebKit, or DRT, or JSC.exe doesn't, and won't unless you
Re: [webkit-dev] Hunspell based spellchecker
Hi Hajime, On Nov 16, 2010, at 8:52 PM, Hajime Morita wrote: Hi WebKit folks, I'm thinking about porting Hunspell-based spellchecking code from Chromium to WebKit/WebCore. Although it's unclear whether the porting is feasible, I'd like to hear how much interest is there from other ports before starting actual work. Because the main goal is to make spellcheck available for more ports, It would be just a waste if there is no demand. For example, I heard that GTK+ has GtkSpell, which is based on Enchant. Because our code is based on Hunspell, GtkSpell based integration is out of scope of this proposal... I have no idea about Qt, EFL, etc. BTW, here is an under-half-baked-rough plan: - Extract spellcheck related methods on EditorClient, to interface (or abstract class) named, say, platform/text/TextChecker. - with keeping existing method, for compatibility - Add a getter like TextChecker* textChecker() = 0; to EditorClient. - Implement TextCheckerHunspell, a subclass of TextCheckerHunspell - TextCheckerHunspellChromium and some other variants will also be added, to make Chromium specific hooks. - (optional) Move Mac's spellchecker implementation from WebCoreSupport/WebEditorClient to platform/text/TextCheckerCocoa, another subclass of TextChecker. - (optional) Remove legacy methods on EditorClient This approach would make spellchecker pluggable, so WebKit can choose preferable spellchecker at runtime with this. (For example, Chromium port wants to use both Hunspell and system spellchecker. GTK port might want use Enchant and Hunspell.) Is this beneficial for your port? Are there other design possibilities? Any feedback is welcome. The wx port is very interested. :) I think this design would do everything that our port needs. We'd probably use the native spellchecker on Mac, and Hunspell on other platforms for now. Thanks, Kevin -- morrita ___ 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] Build system complexity
Hi Maciej, On Aug 13, 2010, at 12:34 AM, Maciej Stachowiak wrote: On Aug 12, 2010, at 2:53 AM, Jeremy Orlow wrote: Are there currently any plans for simplifying the situation regarding build systems? I haven't seen any threads for a while, which I assume means no. Is there any low hanging fruit out there? Since many of the build systems are little more than lists of files, it really seems like we should be able to do some sort of consolidation. Or reduce the process down to updating one file and then running a script that updates/generates the rest. Currently, I cringe every time I find out I need to add a new file. In addition, has anyone ever looked at simplifying the mac port's xcode project? It's _by far_ the heaviest burden on the project given that you pretty much need to use xcode (which is mac only...no other port requires this), exported linker symbols are in a separate file, extra effort to expose a new file in WTF to WebCore, extra effort to expose a new file in WebCore to WebKit, etc. Has anyone recently looked at how the mac build could be simplified--especially from the perspective of contributors whose main development platform isn't a mac? I think we should switch over to export control specified in the headers and not use .exp files any more. WebKit2.framework builds on all its target platforms with no external export control file. The hardest case for this is probably WebCore, though, and I'm not sure how practical it is to do incrementally. Actually, this reminds me of one thing I've been meaning to ask about this regarding moving JSCore export definitions into the headers. The export symbol definitions (such as JS_EXPORTDATA, JS_EXPORT_PRIVATE, etc.) are defined multiple ways in multiple places (e.g. various project's config.h headers), and I was hoping we could move towards having some sort of WTF_EXPORT and WTF_IMPORT macros, then set macros like JS_EXPORTDATA based on them, so that we're not continually copying and pasting the same macro setting logic into each project's config.h or somewhere else. Kind of like a project-wide equivalent to JSBase.h for JSCore public API. You can see this quite well how many places these macros are copied over to by looking at the last patch for https://bugs.webkit.org/show_bug.cgi?id=27551, but that's a pretty large patch, so a simpler case which clearly shows how we need to copy and paste these macros each time a new component needs export symbol control can be found in a patch I recently submitted here: https://bugs.webkit.org/show_bug.cgi?id=43204 One thing that seems to make consolidating these macros into one location tricky is that WTF seems the most suitable place for it, but it is still technically a private implementation detail of JSCore, and there seems to be with some ports a great deal of effort put into isolating each project's headers and sources from the other projects. (With the Windows build particularly, I noticed a lot of copying of headers and even some implementation files from one project to another using the build directory as an intermediary.) I'd like to have some file that could be included by everything from JSCore to DumpRenderTree and, at least indirectly, by client apps (e.g. when I use those macros in wxWebKit API), without having that sort of copying set up in all the ports. Is there currently an appropriate place for such a thing to go? If not, any suggestions on the best way to approach this? Or am I missing some obvious and simple solution here? Thanks, Kevin Regards, Maciej ___ 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] Build system complexity
Hi Jeremy, On Aug 12, 2010, at 7:37 AM, Jeremy Orlow wrote: On Thu, Aug 12, 2010 at 7:18 AM, David Kilzer ddkil...@webkit.org wrote: On Aug 12, 2010, at 3:54 AM, Dumitru Daniliuc d...@chromium.org wrote: i completely agree with jeremy. is it possible to at least drop the cryptic hashcodes/timestamps? without them, the .xcodeproj files should at least be editable by hand. Doesn't gyp already generate Xcode projects for Chrome? I think the issue is that gyp can't generate replacement project files for Apple's Mac port or other build systems yet. That was my take-away from the last discussion--that gyp needed to be enhanced so that all build systems could be generated, making addition or removal of source files a trivial task. Chrome has been using GYP for some time and it's pretty stable. I suspect that anyone trying to port the Mac port's xcode project to it will run into some bugs and/or need to build some additional features into it, but it is quite stable. And the GYP guys are very friendly people though, so I bet they'd be happy to help with any such problems. It's also worth noting that GYP was designed from the start to allow a project to move over to it slowly (you can have custom projects depend on GYP projects and vice versa). But moving to GYP is definitely not the only way to solve this issue--and quite possibly not the best way. I suspect that there are also many smaller steps that could be taken that'd have a big impact. For example, coming up with ways to generate sane/informative error messages for when someone doesn't export some symbol/header file properly would awesome and doesn't require changing the entire build system. Or creating some script that can add files to the xcode project. One project I've been meaning to hack on once I take care of some higher priority work I'm doing is to update WebKitTools/Scripts/update-sources-list.py to pull sources from GYP instead of the code in there to pull sources from (now defunct) Bakefile build system. The idea here is that we can make changes to the source list in one place (say, the GYP files), then run this script and it will update the file lists for other ports that use text-based lists, like GTK, Qt and any ports using CMake. This I think would make updating a lot more straightforward and reduce the need for manually making the same change in 6 different build systems. Adding XCode and MSVC support certainly would be possible too, but if ports using those files are still interested in doing a switch to GYP in the near future, it may not make much sense to bother with it. I've also been working on https://bugs.webkit.org/show_bug.cgi?id=27551, which would allow us to stop using export symbol definition files and instead have the export info in the headers instead, so that all ports can use them rather than having each port define its own export symbols file. That's another thing that I think could reduce a lot of redundant maintenance. Regards, Kevin J ___ 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] DerivedSources.make CPP DOM Bindings
Hi all, I'm working on making the CPP DOM bindings accessible to the wx port, and while I've got the whole thing building, one thing I have yet to sort out is how to add building of the CPP DOM bindings to the build system. DerivedSources.make seems to be the appropriate place to put the code, and it's where I've put things for now, but I wasn't sure if others would feel this is the right place. If I do add it, what is the appropriate way to do it? Should generation be conditional on some define the port will set, like MAKE_CPP_BINDINGS, or should we just directly check for BUILDING_PORT defines? Thoughts? Thanks, Kevin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Python-based unit tests for wx port
Hi all, I'd like to start adding some wx-specific tests for our port's API, at least initially using Python, and since I've noticed a lot of changes being made to the testing infrastructure over the past few months or so (Perl - Python transition, etc.), I was wondering if someone would mind giving me some pointers about where in the tree I should put my tests and how best to integrate them with the overall testing system? Thanks, Kevin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] JavaScriptCore export symbols
Hi all, I'm trying to switch over to building JavaScriptCore as a shared library for the wx port, but one issue I'm hitting is the issue of export symbols. I was wondering how other ports handle this? I know Apple / Win and Apple / Mac have export symbol files, but I'd like to avoid manually creating and maintaining such files, and at the same time, using the Apple / Win and Apple / Mac files seems like it will require a number of adjustments to my build process to get working. (e.g. it wants symbols specific to those ports) So I'm wondering, what are my options here? Would it be acceptable to start adding JS_EXPORT to functions in the JSCore library that are needed by DRT, etc.? Thanks, Kevin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScriptCore export symbols
Hi Kenneth, On May 31, 2010, at 11:09 AM, Kenneth Christiansen wrote: Hi Kevin, They export privately using some files listing the symbols to be exported (mac supports that as so does visual studio, I believe). We cannot do this for Qt, so if you search bugzilla you will find that we have some old patches adding export declarations to the classes being exported (or the individual symbols, if that made more sense) So what's the status on that? From the bug tracker link Ossy sent, it looks like the patch never made it through review, and eventually had the review bit unset because of code rot. Are you guys patching a git branch or something? Thanks, Kevin Cheers, Kenneth On Mon, May 31, 2010 at 3:03 PM, Kevin Ollivier kev...@theolliviers.com wrote: Hi all, I'm trying to switch over to building JavaScriptCore as a shared library for the wx port, but one issue I'm hitting is the issue of export symbols. I was wondering how other ports handle this? I know Apple / Win and Apple / Mac have export symbol files, but I'd like to avoid manually creating and maintaining such files, and at the same time, using the Apple / Win and Apple / Mac files seems like it will require a number of adjustments to my build process to get working. (e.g. it wants symbols specific to those ports) So I'm wondering, what are my options here? Would it be acceptable to start adding JS_EXPORT to functions in the JSCore library that are needed by DRT, etc.? Thanks, Kevin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ 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
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 believe we can automatically convert the XCode project files from binary to plist and back, though IIRC there might be some UUID handling issues to consider), so we could patch the IDE files much like we patch the other ports. As for the other cases, such as additions / removals of things shared by multiple ports and the derived sources problem (that one probably would indeed need some 'template' to insert into project files), I think these could be added over time if we feel it'd bring a large benefit, but I think even just covering the common case of cross-platform source file maintenance is already a huge win for the project. I maintained Bakefile projects for years, and I'd say 80-90% of the time when a change broke my build, it was one of these common source file additions / removals. And it usually happened several times every week. I personally think the way to look at it is to start by solving the simple stuff that could be solved quickly, as in my experience that makes it far more likely to actually get done. If, say, gyp - Gtk / Qt / MSVC (/ XCode?) build file lists could be done in a weekend of hacking and some devs are interested in working on it, why not? Once we start solving problems like that, I suspect we end up with something closer in complexity to Gyp or CMake. True, but I think the real problem that we're not addressing in this discussion is that different ports have different sets of requirements, meaning their own evaluation process would lead them to choose different tools. If we want a 'one size fits all' build system, the first step is getting each port to come together and consolidate the requirements, and there will most likely need to be some compromises involved as some ports may have to agree to move to a tool that's not really as well suited for their project as the one they're using now. For example, a primary reason tools like Gyp and Bakefile exist is that for some people, lack of a 100% native IDE-based build system is a deal breaker. For others, like myself, I want low maintenance, completely cross-platform, highly automated and highly scriptable, which are actually features the IDE projects don't fare very well in. So one man's feature is another man's drawback. There are also factors besides features that are important as well. I think it's also important to remember that from each port's perspective, one potentially big factor in build system choice is also making users comfortable with contributing. For GTK, for
Re: [webkit-dev] [webkit meeting notes] build systems
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? Anyway, the fact that this file is actually Python (I had forgotten the format was JSON-like rather than straight JSON) makes things even better, as we only really need to handle export now, and not parse some import file list. i.e. for WebKitTools/Scripts/update-sources-list.py, getWebCoreFilesDict() basically becomes a very small script that execfile's the gypi file, then we run whatever filtering mechanism on it (waf has a list of ports we could use to do the filtering that I could probably move into WebKitTools/Scripts, if we don't have a pre-made Chromium solution here), and then passes the final source list along to generateWebCoreSourcesGTKandQT to generate the sources / includes for those platforms, and actually this solution should work for Android.mk and possibly jam too, as their syntax looks largely similar. Then we'd add some XML parsing code to grab the node for common file groups and update them for the MSVC projects, and then I think that mostly leaves XCode, which I think would be pretty similar in nature. As long as people are willing to test out this solution with their build systems and help with any debugging, I would be willing to help out in hacking it together, though I can't promise anything in the way of time since this is not an immediate concern for me personally. Thanks, Kevin___ 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
Hi Peter, On Apr 15, 2010, at 9:42 PM, Peter Kasting wrote: On Thu, Apr 15, 2010 at 9:15 PM, Kevin Ollivier kev...@theolliviers.com wrote: 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? I was talking about something far more limited, like converting common build file lists from one format to another. 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. Perhaps, but in any case, I think the first step there is for the Gyp developers to try implementing support and see how it goes. However, from that perspective, until Gyp has support for those formats, isn't a discussion about switching for other ports a bit premature on the WebKit side? i.e. that would be next steps for Gyp, not next steps for WebKit. I'd think Gyp would implement support for those formats and then come here and ask people to consider a switch. Obviously there is something to discuss on the WebKit / Win and WebKit / Mac side since Gyp can already handle those, but at least for the other ports I was thinking of something less involved than a build system migration of that nature (at least, in the sense of moving to it being auto-generated). My suggestion was about leaving the actual build system untouched but having it include a file (or having a script automatically replace a group of source files in the project file) with a generated list of common build files. More like a script that generates a patch for each build system when changes are made to common build files than auto-generating the whole project file(s). This way the ports can continue to work with and maintain their own build system, but when a common build file is added or removed, a script is run that makes a patch for all build systems. I think that would cover a vast majority of the manual hassle involved in managing the cross-platform build files. Regards, Kevin 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
Re: [webkit-dev] [webkit meeting notes] build systems
Hi Nikolas, 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. 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. Of course this is some kind of meta-meta build system, but we could also agree to move the template files in a WebCore/build-templates folder and run a update-project-files script after adding/remove files, that generates the build files, like WebCore.pro and commit them. This way only the person who added/removed a file from build would need to run that script, instead of every one, this would effectively hide the meta-meta build system. If we find an acceptable solution for just adding/removing cross-platform buildable files that it would already make me happy :-) Correct me if I'm wrong, but I thought it would actually be possible to have the values for HEADER_LIST and SOURCE_LIST set in a separate file, and that Qt and GTK build systems could then just include that file. This way we could avoid using templates and such. Just add the included file to the tree (e.g. WebCore/sources.inc) and have the Qt and GTK projects include WebCore/sources.inc and reference those variables. As I mentioned earlier, I actually coded up something using this approach a long time ago back when wx was still using Bakefile, but I guess it never caught the attention of projects like Qt as I never got any feedback on it. (Or maybe the idea was just so obviously flawed somehow. :) Here's the script: http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/update-sources-list.py It would probably not take long at all to have getWebCoreFilesDict pull from a gyp project, XCode project, or whatever we wanted to use as the master file list that should be updated. Thoughts? Thanks, Kevin Looking for comments! Niko ___ 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] [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] Language Bindings
Hi, On Jan 7, 2010, at 5:15 PM, AS wrote: Hello I'm looking into adding bindings for Python to the webkit DOM objects. Ideally, what I would like to create is WebKit based application that can use Python for DHTML manipulation. From the code, I can see how there are perl scripts that parse the idl files and generate binding files, such as those for Javascript and Objective C, I would like to add a set that does the same for Python. From the generated files, I a bit unclear as to where the actual objects are instaniated, i.e. if some jscript created a new say node, is there a table of class names / ctores somewhere? Would it be possible for someone to give a quick overview of what process should be followed to create a new language binding. The wx port actually has this capability to some degree. (Not sure if it has been implemented elsewhere yet.) You can check the wxPython release for Mac and Win (Ubuntu is coming hopefully soon) here: http://wxwebkit.wxcommunity.com/index.php?n=Main.Downloads There's also a sample HTML editor app that uses DOM APIs to do all it's property changes. The source for it is here: http://eclass.svn.sourceforge.net/viewvc/eclass/trunk/htmleditor/htmleditor.py?revision=862view=markup Some methods in that code that touch the DOM are the GetParent method (finds if the current selection is inside a particular tag, such as A) and ShowEditorForTag, which uses a pre-defined attribute list to grab the current value from the DOM, show an editor, and then set the user-specified value on the DOM element when the editor is closed. I haven't landed the bindings yet in trunk as they are a somewhat large project and I'm still working on them. To create them, what I did was add a new bindings generator in WebCore/bindings/scripts that generated C++ bindings. (I based it off the CodeGeneratorCOM.pm script but I had to modify it quite a bit to output COM-free C++ code.) Then I used SWIG to wrap those as Python objects. Regards, Kevin thanks ___ 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] Platform API for Uniscribe/ComplexTextController?
Hi Dan, On Dec 1, 2009, at 8:29 AM, Dan Bernstein wrote: On Nov 29, 2009, at 10:27 AM, Kevin Ollivier wrote: Hi all, The wx port is starting to look at getting proper support for complex text, and one of the first places I started looking at was the Win and Mac port implementations. I noticed that the complex text code in FontWin.cpp and FontComplexTextMac.cpp is largely the same, passing the heavy lifting down to their respective complex text controllers, and I actually wondered if they could be merged if there were some tweaks to the APIs to make them compatible. That led me to wonder if we couldn't make ComplexTextController one of our platform classes and have USE() defines to determine the implementation. Then we could move the drawComplexText, floatWidthForComplexText, and offsetForPositionForComplexText into Font.cpp guarded by that USE() define. The wx port can provide the native font handles the Win/Mac controllers need, so it'd really be great if we could just add these into our build to get complex text support working without having to implement the complex text methods differently for each platform. BTW, I actually already did get UniscribeController compiling, actually, but on Windows I had to have the build script copy it to platform/graphics/wx because MSVC implicitly puts the current directory first on the path, which was causing it to pick up platform/graphics/win/FontPlatformData.h instead of the wx one when compiling that file. :( So that's something else that would need to be addressed if ports can start sharing these files. Thanks, Kevin Hi Kevin, This sounds like a generally good idea. ComplextTextController is already using USE() macros to select between Core Text and ATSUI. I am not entirely sure how the the *ComplexText() methods will be guarded in Font.cpp in your proposal. Are you suggesting something like #if USE(ATSUI) || USE(CORE_TEXT) || USE(UNISCRIBE) || … ? I was thinking we'd create some WTF_USE_COMPLEX_TEXT_CONTROLLER so that it would be easier to opt out of using it, since a port may define / use WTF_USE_ATSUI or WTF_USE_CORE_TEXT for purposes other than supporting complex text. There are still some differences in behavior between ComplexTextController and UniscribeController, so you’d need to find a way to accommodate them or eliminate them. In terms of public API, I think merging the changes shouldn't be too difficult. IIUC finalRoundingWidth() can probably just remain 0 on Win, and the ignore writing direction optimization on Mac can be put in the common API but just be ignored under Windows. The only thing I'm not sure about is that Mac and Win get the run's width in different ways, but I'm not quite sure why they do it differently00. Either approach would seem to work for both platforms. Mac calculates the total width when the ComplexTextController is created, while on Win to calculate it you have to call advance(run.length()) then get the value using runWidthSoFar(). The quick fix would seem to be to just have both platforms call advance(run.length()) and then use runWidthSoFar(), but I suspect that would hurt performance on Mac. Another way that might fix it would be to call advance(run.length()) in UniscribeController::UniscribeController then set m_totalWidth = m_runWidthSoFar and reset m_currentCharacter and m_runWidthSoFar to 0. Lastly, we could take the guts of advance and put it into something like a Win version of adjustGlyphsAndAdvances() that sets total width. Do you have any suggestions / preferences for how to tackle this? I look forward to seeing a patch! Cool, I don't think this will take too long to work up. :) Thanks, Kevin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Platform API for Uniscribe/ComplexTextController?
Hi all, The wx port is starting to look at getting proper support for complex text, and one of the first places I started looking at was the Win and Mac port implementations. I noticed that the complex text code in FontWin.cpp and FontComplexTextMac.cpp is largely the same, passing the heavy lifting down to their respective complex text controllers, and I actually wondered if they could be merged if there were some tweaks to the APIs to make them compatible. That led me to wonder if we couldn't make ComplexTextController one of our platform classes and have USE() defines to determine the implementation. Then we could move the drawComplexText, floatWidthForComplexText, and offsetForPositionForComplexText into Font.cpp guarded by that USE() define. The wx port can provide the native font handles the Win/Mac controllers need, so it'd really be great if we could just add these into our build to get complex text support working without having to implement the complex text methods differently for each platform. BTW, I actually already did get UniscribeController compiling, actually, but on Windows I had to have the build script copy it to platform/graphics/wx because MSVC implicitly puts the current directory first on the path, which was causing it to pick up platform/graphics/win/FontPlatformData.h instead of the wx one when compiling that file. :( So that's something else that would need to be addressed if ports can start sharing these files. Thanks, Kevin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Leak reports during shutdown
Hi Zoltan, On Sep 29, 2009, at 12:39 PM, Zoltan Herczeg wrote: Hi Kevin, WebKit approach is NOT to free memory before quit to make the quit process as fast as possible. The memory manager should free the unfreed objects. However, this approach makes really hard to find the real leaks (which are unreferenced objects). In my experince the unfreed (non-leak) objects come from several sources: - JavaScriptCore garbage collector is not called before quit - Caches are not cleared before quit The previous two are performed by QtLauncher in debug mode. See WebKit/qt/QtLauncher/main.cpp launcherMain() - In case of workers, the gc() does not called for each worker threads when the application quits. The JavaScript threads are simply aborted. - Global objects are not freed at all. There was an attempt to free them (see https://bugs.webkit.org/show_bug.cgi?id=27980 ) but seems not worth to continue that work, although it helped to find leaks such as this: https://bugs.webkit.org/show_bug.cgi?id=29295 The remaining unfreed objects are possible leaks. Many of them are probably port specific (not all port maintainers have resources to keep leak hunters). Thanks for the detailed response, this makes things very clear! :-) ( thanks to Darin for his info about leak checkers) I guess I didn't really expect things to work this way in debug mode as it seems to me RefCountedLeakChecker pretty much needs those resources to be freed in order to provide useful leak reports. In any case, I've been thinking about adding some APIs to manage the cache to wxWebKit and now I've got even more of an incentive to code something up. :-) Thanks, Kevin Zoltan Hi all, For a while, ports like wx and Win/Cairo have been seeing various leaks reported on shutdown, but at least on Mac I've been unable to see these leaks using memory leak checkers like the one in Instruments, so I decided to poke into the code a bit more and try to understand what's going on a bit better. What I found was that the reported object leaks were pretty much all related to objects that JSC has references to. Changing ~ScriptController to do a garbageCollectNow() instead of garbageCollectSoon(), for example, drastically reduced the number of reported leaks, cleaning up all the CachedResource leaks and almost all the WebCoreNode leaks. The remaining leaks were almost all JSC::Structure objects. I've been digging through the code to try and find the place where these JSC objects are finally deleted, but I haven't found anyplace obvious in the code, neither in common code nor in the ports' code. My question is, is there somewhere these objects are being deleted on final shutdown that apparently happens after the leaks are reported, or does WebKit have assumptions such as that all still running timers must fire before final shutdown that ports such as ours are not honoring? (e.g. in my tests garbageCollectSoon() does not end up firing the callback because the app shuts down too fast.) Thanks, Kevin ___ 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] waf build patches
Hi all, Well, I've finally submitted the patches for building wxWebKit using waf. They're available from here: https://bugs.webkit.org/show_bug.cgi?id=27619 I've tried to keep the patches how you guys like them - under 5KB each. ;-) There's only 6, with one being about 20KB but that can be broken up too if requested. (Though they're basically helper scripts so I suspect they just need a look over.) If I could get some quick reviews on these, it'd be really appreciated as trunk simply doesn't build for wx right now, and although I have a git branch that still builds, it's against sources that are becoming increasingly dated and so I'd like to be able to update it and get everything back on track. Also, as a heads up, I'm heading out on vacation Saturday, so if these get reviewed after that I probably won't be able to apply them until week after next. So if I don't apply them right away it's not because I don't want to. ;-) Also #2, just for anyone curious, I was able to get it working so that the list of sources to compile is generated automatically using an excludes mechanism. I'd certainly be happy to help anyone who is interested in making the exclude patterns configurable based on port. As you can see from the patches, I only had to explicitly add (or remove) a dozen or so sources. Everything else is generated simply by telling it to build all non-port-specific sources in common dirs plus sources in wx and CURL directories, so I feel pretty confident that this could be adapted to build other ports fairly quickly. Thanks, Kevin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)
Hi Peter, On Jul 13, 2009, at 2:03 PM, Peter Kasting wrote: On Mon, Jul 13, 2009 at 1:56 PM, Maciej Stachowiak m...@apple.com wrote: One belated comment on this topic. It would be neat if some port agreed to be the guinea pig to see if gyp could plausibly work for more than Google's ports. The Wx port probably has the lowest resources of any complete port in the tree, so they might not be the best choice of experimental subject, particularly if for them the process required writing a new gyp back end and if they are not yet entirely comfortable going the gyp route. Another note, based on some #chromium conversations: if someone passionate made CMake (or any other tool) into something compelling enough to work better for Chromium than gyp does (or at least to work close-to-as-well), and that tool was more plausible for other ports in the WK tree to adopt, we wouldn't be opposed in principle to using it. The potential benefits of a shared build system are clear, and we're not trying to tell people that system has to be gyp; we're just probably not prepared to be the ones to go determine other ports' needs and decide on the Build System To Rule Them All. If no one wants to do this, but other ports do want to try gyp, we can lend them a hand in checking it out too. Whatever makes things at least a little easier. After reading Mark's comments, one idea that has been stewing around in my head is seeing if it would be possible to have waf optionally call the GYP GenerateOutput methods directly, instead of doing a build, by converting the final, computed compiler/linker settings into a GYP-friendly series of lists/dicts. If that could be made to work, it would offer the best of both worlds. On one hand, we have a fast and scalable build system that can be extended to do pretty much anything you can code up in Python, and on the other, you can still use IDE projects if that's what you're comfortable with. Of course, the big question is if waf would have the same limitations as SCons in regards to doing this, but I think it's at least worth exploring. I'd be interested to know what limitations you guys ran into when trying to use SCons for this sort of thing. Of course, there will always be some things that would be hard to do with the IDE projects, but it may be possible for us to make use of waf there too, by using command line arguments to have it, for example, only generate the derived sources, which we could call from the IDE projects. Thoughts? Thanks, Kevin PK ___ 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] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)
Hi Peter, On Jul 14, 2009, at 10:27 AM, Peter Kasting wrote: On Tue, Jul 14, 2009 at 9:24 AM, Kevin Ollivier kev...@theolliviers.com wrote: Of course, the big question is if waf would have the same limitations as SCons in regards to doing this, but I think it's at least worth exploring. I'd be interested to know what limitations you guys ran into when trying to use SCons for this sort of thing. Of course, there will always be some things that would be hard to do with the IDE projects, but it may be possible for us to make use of waf there too, by using command line arguments to have it, for example, only generate the derived sources, which we could call from the IDE projects. I don't really know enough about either waf or SCons to comment. My impression as a naive observer was that SCons had serious speed issues with our build (especially the overhead for a null build). Yeah, I hit the same problems as well, and after some profiling and discussions on the SCons mailing list, came to the conclusion that SCons simply had architectural issues that made it a poor choice for a large project like WebKit. The overhead for waf is minimal, though, and quite possibly even less than make on Unix systems. Some benchmarks done have shown it to be significantly faster than make, in fact, which is my subjective opinion as well. My Windows builds also feel noticeably faster, but then again I was using .vc makefiles, which meant I couldn't do parallel builds there. ;-) I just haven't had time to really sit down and benchmark. Thanks, Kevin PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)
Hi Jeremy, On Jul 10, 2009, at 6:54 PM, Jeremy Orlow wrote: On Fri, Jul 10, 2009 at 6:26 PM, Kevin Ollivier kev...@theolliviers.com wrote: Hi Jeremy, On Jul 10, 2009, at 3:03 PM, Jeremy Orlow wrote: [snip] Your argument makes sense if WebKit is only built for one platform/ build-system. Unfortunately it's not. So the question is whether it's easier to maintain lots of different build files or whether it's easier to maintain one file that's perhaps a bit more abstract + the tool that interprets it. I agree that working directly in the project file for your platform is easier IF you're only developing for one platform. But once you start maintaining more than one project file, I think GYP is a big win. While we hope that others will update our GYPI file when they add/ remove files, our build depends on it...so we'll definitely be keeping it in sync. So I think the question then becomes whether it's easier for you to maintain your new build format, or whether it's easier to make it a target for GYP. I honestly don't know what the answer is, but I think it's worth taking a closer look at GYP. Actually, the big question in regards to having GYP reduce overall project maintenance is whether or not the other ports will adopt GYP. If the answer is yes, then it would be more compelling for wx to do so as well, assuming of course that someone implements a waf backend so that we can. :-) If the answer is no, though, then GYP is not reducing the amount of project maintenance work for any port other than Chromium, in which case there will still be 6 build systems (still 5 even if wx were to switch) and the problem I originally posed in this thread will still be an issue. In that case, the only way to really reduce the maintenance work of adding / removing files would again be to adopt a script like the one I suggested earlier. You're right. The burden of updating the GYPI file is less than the others, but it's still another file you need to change. But note that the maintainers of each project/platform/etc define which files to exclude. This is different from the other build systems where the person updating the file needs to decide whether it should go into the build or whether it should only be built with certain flags. Speaking of which, with waf / Python I've actually almost completely automated the generation of the list of include dirs for my build projects based on the source files, so that I'm not maintaining them by hand anymore except for a few exceptions. And thinking about it, I bet I can even mostly automate the list of source files too, by having it grab all the .cpp files in the common dirs and special subdirs like curl and wx, then having some include / exclude filters to deal with a few special cases. :-) The question will be the performance hit, but at least with the includes it's not even noticeable, and I could always look into caching and changing only when you do an svn up or svn add/remove. I suggest you take a look at GYP. Much of what you're talking about it already does. Of course, GYP (and Bakefile, too) supports a wildcard file matching and exclusion mechanism, but that's not really as flexible as what I'm talking about. I'm talking about something that calculates and then traverses a list of subdirectories where even the set of subdirectories traversed are conditional upon variable values set earlier in the build. It's certainly possible what I'm asking for could be made to work, but in the end if I did get it going I'm pretty sure that I would be very unhappy with the syntax because, quite simply, a data format is not really designed to support recursion, looping and the like. It's, well, designed for storing data, which is why even conditionals are expressed in GYP using nested lists and property=value syntax. So the bottom line for me is not really that I couldn't figure out a way to use GYP, as after all I've been using something like it for years, rather that when I need more flexibility and more control, the way to get that using a format like Bakefile or GYP does not feel natural or intuitive; it's more like trying to squeeze a square peg into a round hole. Even the question of where should the change go - extend GYP, throw it somewhere in build-webkit, write a build command that spits its output to GYP, etc. can become a difficult question. As for waf, the only question is whether the change should go in the common portion of the build system, or in a project-specific part, and refactoring as needs change is simple and straightforward, meaning I'm more likely to just do it rather than settle for 'good enough' just because refactoring would require extending the project generator tool, etc. GYP's primary goal is to generate IDE project files, because that's what apparently many ports want. Since IDE projects have many
[webkit-dev] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)
Hi Dimitri and all, Congrats on getting this into WebKit! Actually, I'm in the middle of a build system switch as well - to waf, a re-write of scons that removed many of the performance issues related to searching and calculating dependencies, and which has added some nice features as well (such as .app bundle building). I haven't completed the switch so I can't do preliminary benchmarks, but I'm pretty sure it's actually as fast or faster than make on *nix/Mac. (And BTW, it will probably make Apple devs happy to hear that I'm no longer using the horrid build-wxwebkit bash script to manage the build, but instead have integrated everything into build-webkit finally!) The main reason I bring this up, though, is because I think this sort of thing shows that we're unlikely to centralize our build systems any time soon, and I feel a bit sorry for the core devs who, as they accept new ports, are probably finding it more and more tedious, if not difficult, to make sure all the projects get updated by a change to the common parts of the build. They've been very helpful in terms of trying to keep the ports in shape when they make changes, and I feel like I'd like to do what I can to make it easier and faster to keep the other ports in sync. At one point, I started on a script (located in WebKitTools/Scripts/ update-sources-list.py) whose idea was to take the list of common sources from one file, and make changes to MSVC, Qt, GTK, etc. build systems, so that WebKit devs need only add the file once, run the script, and commit the results. I got it as far as theoretically generating the Qt and GTK file lists, but I don't think anyone on those ports tried integrating it into their build system, and I sort of moved on to other things. Unfortunately, right now I'm really swamped (my build system rewrite was prompted by WebKit exceeding internal, hardcoded, Bakefile limits, not by choice), but if a common location for the source files list could be decided upon, I really think a script would be a simple matter to write up (even in Perl :P ), and I think it would probably save developers time and reduce build breakages as well, which I think would add up to a lot of saved time for a lot of people over the long term. The only format I'm not sure if we could automate reliably would be the XCode format (at least, on non-Mac machines), because IIUC we'd need some sort of parser for it, but Apple is the only port maintaining those directly IIUC, as now Chromium will be using GYP to update their XCode projects. So even if we couldn't solve the XCode issue, that would drop it to updating two locations tops. So, does anyone think this would be a bad idea, or have any alternate suggestions on how to improve things? If not, is anyone willing to take the ball and run with it? I'd be willing to invest some more time in it, but my ability to commit to it over the next couple weeks at least would be very limited. Thanks, Kevin On Jul 9, 2009, at 9:23 PM, Dimitri Glazkov wrote: Dear WebKiteurs, In our persisting quest to be more like a common WebKit port, we have added Chromium build files to the tree this afternoon. These files are WebCore/WebCore.gypi and JavaScriptCore/JavaScriptCore.gypi and they are the GYP include files. As you may know, we use GYP (http://code.google.com/p/gyp) for generating MSVC, XCode, Scons, and even Make projects for Chromium. We are rather fond of GYP. Perhaps it is because it allows us to maintain one set of project files for all three Chromium platforms; or maybe because it lets us to do things like WebCore.gypi, where we can just mindlessly add all project files to the list and then use various neat GYP filtering facilities to narrow them down to sets that are relevant for specific builds; or maybe because it easifies creating cross-platform and cross-build-system targets, actions, and rules; or maybe because we just love saying Gyp! I don't truthfully know. What I do know is that starting now, we'd love for you to remember WebCore.gypi and JavaScriptCore.gypi when you are adding or removing files from WebCore or JavaScriptCore. Thanks to the power of GYP, you don't have worry whether this file will be used by Chromium: the rule is that if there's a project file change, it applies to the *.gypi files. The format is very simple and intuitive, a simple Python/JSONey list+dict. Thank you for your attention, men and women of WebKit. :DG ___ 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] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)
Hi David, On Jul 10, 2009, at 11:06 AM, David Kilzer wrote: So, does anyone think this would be a bad idea, or have any alternate suggestions on how to improve things? What about adding support for waf to gyp? If we're talking about Chromium, waf is much faster for building WebKit than scons is, so yeah, I would say adding the ability to use it instead of scons is a no-brainer. As for wx, while I'm open to the idea of using gyp to help others out or simplify matters for the core devs, for us I'm pretty sure it will mostly just be one more added layer to our build system. I've been using Bakefile for years now and while I thought the idea was great at first, I've found it mostly a pain to work with. Some of that is due to Bakefile itself, of course (like the latest bug...), but a lot of it is just the general approach and issues inherent with adding one more tool to the toolchain. Even though there's some sort of meta-tool generating the build projects, it only reduces, not removes, the need to understand and deal with the native project formats it outputs. Also, since the meta-tool can have bugs or missing features too, there's an additional point of failure added, and also added work in terms of maintaining the build system. Plus, any time you want to add a feature, you should look into how to implement it in the various formats that gyp supports to avoid hacks, a process which can sometimes require pretty creative solutions for less capable build tools. And there's also the fact that, if wx uses gyp, people are going to start asking for support for their favorite project format, which is just one more thing to deal with. In short, I think I've just come to be soured on the approach in general. I think I've come to agree with the point that the waf site makes about domain-specific languages not being a good idea for build systems, and when you use a tool like Bakefile or gyp, you not only need to become familiar with that tool's project file language, but also to some level with the formats of the project files that it outputs in order to debug or add new capabilities. With waf, all I ever really need to know is Python, which I already know, and the waf APIs, which I'm learning but for the most part have been pretty simple and straightforward to work with. The bottom line for me is that anything that has me spending less time on maintaining the build system and more on the actual product is a good thing in my book. ;-) Thanks, Kevin The only format I'm not sure if we could automate reliably would be the XCode format (at least, on non-Mac machines), because IIUC we'd need some sort of parser for it, but Apple is the only port maintaining those directly IIUC, as now Chromium will be using GYP to update their XCode projects. If you hand-edit Xcode project files enough times you start to understand them, but you also may go insane in the process. I don't know that you have to write a full parser for it, but there is some non-trivial, minimal structure you have to understand to update the file properly. So even if we couldn't solve the XCode issue, that would drop it to updating two locations tops. I count 6 build systems in use currently (SCons support was added and removed within the last year): - Apple's Xcode - Apple's vcproj (also used by at least one other Windows port) - wx Bakefile (which will be replaced by waf soon) - Qt Qmake - GTK GNUMakefile - Google's gyp (added recently) Are any of the other ports going to switch to generating their build files using gyp? Dave - Original Message From: Kevin Ollivier kev...@theolliviers.com To: Dimitri Glazkov dglaz...@chromium.org Cc: Mark Mentovai m...@chromium.org; WebKit Development webkit-dev@lists.webkit.org Sent: Friday, July 10, 2009 8:52:57 AM Subject: [webkit-dev] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family) Hi Dimitri and all, Congrats on getting this into WebKit! Actually, I'm in the middle of a build system switch as well - to waf, a re-write of scons that removed many of the performance issues related to searching and calculating dependencies, and which has added some nice features as well (such as .app bundle building). I haven't completed the switch so I can't do preliminary benchmarks, but I'm pretty sure it's actually as fast or faster than make on *nix/Mac. (And BTW, it will probably make Apple devs happy to hear that I'm no longer using the horrid build-wxwebkit bash script to manage the build, but instead have integrated everything into build-webkit finally!) The main reason I bring this up, though, is because I think this sort of thing shows that we're unlikely to centralize our build systems any time soon, and I feel a bit sorry for the core devs who, as they accept new ports, are probably finding it more and more tedious, if not difficult
Re: [webkit-dev] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family)
Hi Jeremy, On Jul 10, 2009, at 3:03 PM, Jeremy Orlow wrote: [snip] Your argument makes sense if WebKit is only built for one platform/ build-system. Unfortunately it's not. So the question is whether it's easier to maintain lots of different build files or whether it's easier to maintain one file that's perhaps a bit more abstract + the tool that interprets it. I agree that working directly in the project file for your platform is easier IF you're only developing for one platform. But once you start maintaining more than one project file, I think GYP is a big win. While we hope that others will update our GYPI file when they add/ remove files, our build depends on it...so we'll definitely be keeping it in sync. So I think the question then becomes whether it's easier for you to maintain your new build format, or whether it's easier to make it a target for GYP. I honestly don't know what the answer is, but I think it's worth taking a closer look at GYP. Actually, the big question in regards to having GYP reduce overall project maintenance is whether or not the other ports will adopt GYP. If the answer is yes, then it would be more compelling for wx to do so as well, assuming of course that someone implements a waf backend so that we can. :-) If the answer is no, though, then GYP is not reducing the amount of project maintenance work for any port other than Chromium, in which case there will still be 6 build systems (still 5 even if wx were to switch) and the problem I originally posed in this thread will still be an issue. In that case, the only way to really reduce the maintenance work of adding / removing files would again be to adopt a script like the one I suggested earlier. Speaking of which, with waf / Python I've actually almost completely automated the generation of the list of include dirs for my build projects based on the source files, so that I'm not maintaining them by hand anymore except for a few exceptions. And thinking about it, I bet I can even mostly automate the list of source files too, by having it grab all the .cpp files in the common dirs and special subdirs like curl and wx, then having some include / exclude filters to deal with a few special cases. :-) The question will be the performance hit, but at least with the includes it's not even noticeable, and I could always look into caching and changing only when you do an svn up or svn add/remove. That's the sort of flexibility and ability to quickly experiment and automate that scripts offer, and I suspect I will really miss that if I switch back to something like Bakefile / GYP. Thanks, Kevin J Thanks, Kevin The only format I'm not sure if we could automate reliably would be the XCode format (at least, on non-Mac machines), because IIUC we'd need some sort of parser for it, but Apple is the only port maintaining those directly IIUC, as now Chromium will be using GYP to update their XCode projects. If you hand-edit Xcode project files enough times you start to understand them, but you also may go insane in the process. I don't know that you have to write a full parser for it, but there is some non-trivial, minimal structure you have to understand to update the file properly. So even if we couldn't solve the XCode issue, that would drop it to updating two locations tops. I count 6 build systems in use currently (SCons support was added and removed within the last year): - Apple's Xcode - Apple's vcproj (also used by at least one other Windows port) - wx Bakefile (which will be replaced by waf soon) - Qt Qmake - GTK GNUMakefile - Google's gyp (added recently) Are any of the other ports going to switch to generating their build files using gyp? Dave - Original Message From: Kevin Ollivier kev...@theolliviers.com To: Dimitri Glazkov dglaz...@chromium.org Cc: Mark Mentovai m...@chromium.org; WebKit Development webkit-dev@lists.webkit.org Sent: Friday, July 10, 2009 8:52:57 AM Subject: [webkit-dev] Build File Maintenance (was Re: Please welcome GYP to the our dysfunctional build family) Hi Dimitri and all, Congrats on getting this into WebKit! Actually, I'm in the middle of a build system switch as well - to waf, a re-write of scons that removed many of the performance issues related to searching and calculating dependencies, and which has added some nice features as well (such as .app bundle building). I haven't completed the switch so I can't do preliminary benchmarks, but I'm pretty sure it's actually as fast or faster than make on *nix/Mac. (And BTW, it will probably make Apple devs happy to hear that I'm no longer using the horrid build-wxwebkit bash script to manage the build, but instead have integrated everything into build-webkit finally!) The main reason I bring this up, though, is because I think this sort of thing shows that we're unlikely to centralize our build
Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
Hi Maciej, On May 25, 2009, at 12:33 AM, Maciej Stachowiak wrote: On May 24, 2009, at 10:38 PM, Adam Barth wrote: On Sun, May 24, 2009 at 10:08 PM, Maciej Stachowiak m...@apple.com wrote: I don't think it should be discounted. It might be helpful to clarify why you think ifdefs are a bad solution. When I made changes that affect several ports, I try to be good WebKit citizen and update all the ports, but the situation we have today makes that a pain. For example, consider the case of adding a method to ChromeClient. I understand that I have to add the method to a bunch of port-specific subclasses, but theses classes are stored in slightly different locations (WebCoreSupport or WebKitSupport?), have different naming conventions (WebChromeClient or ChromeClientGtk?), and have different names spaces (using namespace WebCore or not?). All these issues combine to ensure that I've screwed it up, and I don't really have a way to test because I can't building the XYZ port. I just have to check in my change and pray. Anyway, that's my rant. Are patches welcome for homogenizing some of these idiosyncrasies? I would be in favor, though in general we leave the WebKit layer up to port owners. Maybe others would like to chime in. Personally, I'd be in favor of some defined conventions that ports are at least suggested to follow. I don't think homogenizing the Web(Kit | Core)Support layer would be a big problem for porters, and I think it's definitely worth doing if it makes it easier for you guys to make changes to the ports. In hindsight, while we used WebKitSupport for the wx port, I think WebCoreSupport is probably the better choice, or perhaps even WebCoreClients would be more appropriate. Regarding the file names, I think most ports use the convention of WhateverClientPort. I think actually the Apple ports are the only ones using the WebWhateverClient convention. While I can go either way, I do like the WhateverClientPort convention, myself. Regardless, if we decide on a particular convention or guideline, I will happily update the wx port to use it! :-) I think one key step here will be to have a try server integrated with the buildbots, so that it's at least practical to test such patches. I definitely second this, it would be enormously helpful! :-) Thanks, Kevin Regards, Maciej ___ 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] Review Queue
Hi Eric, On May 21, 2009, at 9:47 PM, Eric Seidel wrote: Interesting analogy. However, closing means to me that the community is done with the bug. Denying a patch because no one's working on it anymore (aka, no one is there to respond to review comments even if you make them) is not the same as closing a bug. There is a forgotten patches link on the nightly start page iirc which shows all the r-'d patches. :) http://nightly.webkit.org/start/ I've certainly looked through that list for patches to finish before. Maybe I'm the only one. Many of the bugs we see languish in the review queue are just too big to be easily reviewed. I don't think we encourage enough decisive action from reviewers (like just r-ing a patch because it's too big to review). At least an r- action gives the contributer something more than silence. :) This could of course all be avoided if we got our review queue down to something manageable. :) My issue with this is that doing r- doesn't really solve the problem, it just makes the patch magically seem to disappear from the review queue. In general, I think it does make sense to prune really old patches and bugs periodically, but 2 weeks is way too fast IMHO (and even 1 month probably), even considering bit rot, and what I don't understand is why you want to put the burden on patch submitters to resubmit because their patches aren't getting reviewed? I don't see how this helps patches to get reviewed; in fact, quite the opposite - they may magically disappear from the queue on just the day someone might have decided to check the queue and actually review it. I do understand the frustration, as I've had my fair share of patches sit for a while awaiting review, but from what I can tell all your changes will do is just make it even more work for me to try and get a review. In addition to going around trying to find someone to review my patch, now I have to periodically resubmit too. And this gets my patch reviewed faster how? I do think there are real issues to be discussed here, and I think some of the ideas presented in other posts in this thread are worth taking a look at, but I just feel this approach is more a knee-jerk reaction rather than a real strategy to fix the review queue problem. Regards, Kevin We're down to 95 after today. (We were at 144 two days ago!) curl -s https://bugs.webkit.org/request.cgi; | grep PDT | wc -l 95 -eric On Fri, May 22, 2009 at 2:38 PM, Maciej Stachowiak m...@apple.com wrote: On May 21, 2009, at 9:36 PM, Geoffrey Garen wrote: Our current defacto policy requires involvement on both sides. Submitters need to be involved in finding people to review their patches. Posting patches to the review queue does not automatically get you a review, except occasionally by Darin Adler or myself. If a bug totally stalls, and is sitting in the review queue untouched I view that as the responsible reviewers' implicit rejection of the patch. I, as a responsible reviewer, am simply making explicit that implicit rejection. Personally, I'd rather get an r- on my patches than have them sit ignored for multiple weeks at a time. Let's examine these statements in a broader light, substituting bug database for review queue and bug for patch: Our current defacto policy requires involvement on both sides. Submitters need to be involved in finding people to fix their bugs. Filing bugs to the bug database does not automatically get you a fix, except occasionally by Darin Adler or myself. If a bug totally stalls, and is sitting in the bug database untouched, I view that as the responsible reviewers' implicit rejection of the bug. I, as a responsible reviewer, am simply making explicit that implicit rejection. Personally, I'd rather get a closed on my bugs than have them sit ignored for multiple weeks at a time. So, Eric, should we close all bugs that are older than 2 weeks? I thought of the same analogy, and for this reason I disagree with Eric's proposed change. Marking patches r- without review feedback is impolite to the patch submitter, and loses valuable information. Regards, Maciej ___ 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] Libcurl backend build error (was: build on ubuntu not working as expected)
Hi Antonio, Yes, I've fixed it now, sorry. Thanks, Kevin On May 20, 2009, at 5:41 AM, tonikitoo (Antonio Gomes) wrote: Hi, That is something reproducible by every one who builds libcurl as network backend in a non-debug build, and really has to be fixed. Code looks like this: (...) WebCore/platform/network/curl/ResourceHandleManager.cpp #ifndef NDEBUG char* url = 0; curl_easy_getinfo(d-m_handle, CURLINFO_EFFECTIVE_URL, url); fprintf(stderr, Curl ERROR for url='%s', error: '%s'\n, url, curl_easy_strerror(msg-data.result)); #endif if (d-client()) d-client()-didFail(job, ResourceError(String(), msg-data.result, String(url), String(curl_easy_strerror(msg-data.result; (...) NOTE: url is declared inside the IFNDEF and used if the if statement outside that, which is obviously wrong. Problem: I build revision 41937 sometime back and wxBrowser and my own wxPython browser was working fine Today i updated to revision 43688. 1. First I got an error at line 329 platform/network/curl/ResourceHandleManager.cpp url not defined in this scope so i moved out char* url out of #ifndef NDEBUG -- --Antonio Gomes ___ 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] build on ubuntu not working as expected
Hi Anurag, Sorry, I looked at the subject and took it to be a GTK issue. Anyway, yes, I'm seeing the problem on Ubuntu as well, though I'm not seeing it on Mac. It seems as if something is causing page loads to hang, but it may take me some time to track down exactly where the hang is happening. When I run it in a debugger I do not even get it loading the google.com HTML content. Thanks, Kevin On May 19, 2009, at 8:45 AM, David Kilzer wrote: Yes, your messages are getting to the list. Your best bet is to contact the wxWebKit maintainer, Kevin Ollivier, who I've copied on this message. Dave From: anurag uniyal anuraguni...@yahoo.com To: webkit-dev@lists.webkit.org Sent: Tuesday, May 19, 2009 8:13:36 AM Subject: Re: [webkit-dev] build on ubuntu not working as expected Can anybody confirm this is getting to the list? From: anurag uniyal anuraguni...@yahoo.com To: anurag uniyal anuraguni...@yahoo.com; webkit- d...@lists.webkit.org Sent: Sunday, 17 May, 2009 9:36:49 AM Subject: Re: [webkit-dev] build on ubuntu not working as expected can anybody give any pointers? From: anurag uniyal anuraguni...@yahoo.com To: webkit-dev@lists.webkit.org Sent: Friday, 15 May, 2009 3:34:55 PM Subject: [webkit-dev] build on ubuntu not working as expected I first posted it on webkitsdk-...@lists.apple.com but was redirected here. Hi, I am facing problem in running latest build on ubuntu. Problem: I build revision 41937 sometime back and wxBrowser and my own wxPython browser was working fine Today i updated to revision 43688. 1. First I got an error at line 329 platform/network/curl/ ResourceHandleManager.cpp url not defined in this scope so i moved out char* url out of #ifndef NDEBUG after that build was successful, regresion test also passed except few date test which were same in last revision too 2. now wxBrowser does not work as expected e.g. on opening www.google.com a) it takes too much time b) image are not displayed c) it doesn't go to any other link, just stuck at loading... for build I used ./set-webkit-configuration --release ./build-webkit --wx --wx-args=wxgc wxpython my system is GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7) Linux-2.6.24-19-generic-i686-with-debian-lenny-sid' Any tips are appreciated. Thanks Anurag From Chandigarh to Chennai - find friends all over India. Click here. Share files, take polls, and make new friends - all under one roof. Click here. Explore and discover exciting holidays and getaways with Yahoo! India Travel Click here! Cricket on your mind? Visit the ultimate cricket website. Enter now! ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Dump render tree of webkit
Hi Meryl,
On May 14, 2009, at 9:08 AM, Meryl Silverburgh wrote:
On Thu, May 14, 2009 at 9:11 AM, Ariya Hidayat
ariya.hida...@trolltech.com wrote:
layer at (0,0) size 800x600
RenderView at (0,0) size 800x600
layer at (0,0) size 800x600
RenderBlock {HTML} at (0,0) size 800x600
RenderBody {BODY} at (8,8) size 784x584
This the render tree. Or did you mean something else?
Thanks. But I was trying it with http://www.cnn.com, it has more than
just a BODY tag, so I am not sure why it does not show the rest, which
is what I care about.
The first line of the output gives you the reason. It says: Blocked
access to external URL http://www.cnn.com/; The render tree you see is
most likely that of a blank page used after it couldn't load cnn.com.
It looks like DRT currently doesn't offer a way to disable that
blocking, though it could probably be added with some hacking. Looks
like the block is happening inside WebKitTools/DumpRenderTree/mac/
ResourceLoadDelegate.mm.
Regards,
Kevin
Moreover , is there any tool/function to dump the DOM of a page to
file/screen?
I guess you could something similar (inspecting the DOM etc) from
the Web
Inspector.
I am looking for something write to a file/screen to dump the whole
DOM instead of clicking an element at a time.
Thank you.
--
Ariya Hidayat, Software Engineer
Qt Software, Nokia Devices RD
___
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] JS_EXPORT addition
Hi all, I'm trying to update the wx port after the addition of JS_EXPORT and the idea of exporting symbols. However, I'm noticing that jsc.cpp, for example, uses numerous functions / classes which are not part of JavaScriptCore/API and are not declared with JS_EXPORT. How is it that jsc.exe is being linked properly while using private functions of JavaScriptCore.dll on the Apple / GTK ports? Thanks, Kevin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Windows build ENABLE(ASSEMBLER)
Hi all, I'm trying to get a box ready to be a Windows build bot for the wx port, and while trying to build WebKit I've come across an issue with ENABLE(ASSEMBLER). Apparently this gets enabled only for Safari Win or Mac as it depends on HAVE(JIT) or HAVE(WREC) being set, but if HAVE(VIRTUALALLOC) is true (which is set to true under PLATFORM(WIN_OS)), then JavaScriptCore/interpreter/RegisterFile.h wants to use the roundUpAllocationSize function, which is only defined when ENABLE(ASSEMBLER) is true. Obviously I could play around with doing things like enabling JIT, but I'm kind of wondering what my options are in terms of what is portable beyond the Apple ports, and what might be the best option for the wx port at this point in time. Any advice would be greatly appreciated! :-) Thanks, Kevin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HAVE_LANGINFO_H and OS X
Hi Darin, On Mar 23, 2009, at 12:55 PM, Darin Adler wrote: But I think that all DARWIN-targeted ports and indeed any port where PLATFORM(CF) is true, should use the superior version based on CFDateFormatter. That’s an even better fix for Mac OS X. Thanks, I've put the more limited fix up here: https://bugs.webkit.org/show_bug.cgi?id=24780 I plan to look into the CF stuff at some point, but as I noted in the bug we don't define PLATFORM(CF) yet so I'd rather go with the fix I know works until I have more time to experiment with enabling CF. Thanks, Kevin -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Is there any Windows-GDI-only port?
Hi Adam, On Mar 23, 2009, at 7:28 AM, Adam Roben wrote: On Mar 23, 2009, at 6:18 AM, 김인기 wrote: I want to port WebKit to Windows-Mobile device. But, I could find only CoreGraphics-port and Cairo-port. Is there no Windows-GDI-only port? That is correct, there is no Windows port that only uses bare GDI calls for drawing. Actually - the wx port does have a mode using GDI under the hood. Digsby currently uses it over the GDI+ mode for performance reasons, but they AFAICT don't need to worry about the missing features caused by using it. Regards, Kevin___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] HAVE_LANGINFO_H and OS X
Hi all, Gustavo Noronha recently wrote me and pointed out that he did some work on the GTK port to fix a JSCore test (http://trac.webkit.org/changeset/41909 ), and said he thought that the fix might also apply to the JSCore regression we see on the wx port. It does in fact fix the problem, but to get the fix I need to explicitly #define HAVE_LANGINFO_H 1 on Mac. I'm wondering if it's safe to define it to 1 for all ports building under Darwin, or if I should keep the fix isolated to the wx port? Thanks, Kevin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] BUILDING_ON_TIGER/LEOPARD macros
Hi Mark, Thanks for the detailed explanation! I just landed a fix based on your suggestions. It built okay with both the wx and Apple ports, but if it causes anyone trouble, please let me know! Thanks, Kevin On Mar 14, 2009, at 7:31 PM, Mark Rowe wrote: On 2009-03-14, at 10:49, Kevin Ollivier wrote: Hi all, I'm seeing some strangeness with the OS X availability macros. First, it looks like BUILDING_ON_TIGER and BUILDING_ON_LEOPARD are defined in JavaScriptCorePrefix.h, which AFAICT is only used by the Apple XCode projects, yet the use of these macros are often inside PLATFORM(DARWIN) rather than PLATFORM(MAC) checks, meaning other ports building on Mac will need them too. Second, even after I tried moving them to Platform.h, the MAX_ALLOWED = MAC_OS_X_VERSION_10_5 check doesn't work for me, because apparently MAX_ALLOWED is defined to the actual latest release on my machine (1056) rather than (1050), and so the check doesn't pass and so it sets things up as if I'm running something post-Leopard, which I only wish I were doing... ;-) Checking MAX_ALLOWED = 1056 does get things going right again. The use of the BUILDING_ON macros inside PLATFORM(DARWIN) blocks may all be recent additions. I introduced one such use earlier this week, and I believe Darin may have done so as well. I'm not sure whether there were any instances of this prior to those two changes. Moving the macro definitions in to wtf/Platform.h so that they can be used by other ports building on Mac OS X seems reasonable to me, but we may need to tweak them slightly to work with ports that aren't aware of the SDK and deployment target mechanisms that Mac OS X's compiler toolchain provides. For some background: the way these macros are intended to function is that MAC_OS_X_VERSION_MIN_REQUIRED indicates the minimum version of the operating system that the binary will run on, while MAC_OS_X_VERSION_MAX_ALLOWED indicates the maximum version of the operating system that you intend to take advantage of. Symbols introduced in OS versions between MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED will be weak-linked, and symbols introduced after MAC_OS_X_VERSION_MAX_ALLOWED will be unavailable for use. When building via Xcode these values are typically derived from two configuration settings: the SDK that your project is targeting (corresponding to GCCs -isysroot argument), and the deployment target (-mmacosx-version-min). If you build against the MacOSX10.5 SDK with a deployment target of 10.4 you will see that MAC_OS_X_VERSION_MIN_REQUIRED is set to 1040 and MAC_OS_X_VERSION_MAX_ALLOWED is set to 1050. If you don't build against an SDK or specify a deployment target then both MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED will default to your current Mac OS X version (eg, 1056), and the compiler happily let you use functionality that would prevent your application from running on previous versions of Mac OS X. The Mac build of WebKit explicitly sets a deployment target equal to the major version of the Mac OS X version that you are on. This results in both MAC_OS_X_VERSION_MIN_REQUIRED and MAC_OS_X_VERSION_MAX_ALLOWED being set to the major component of the Mac OS X version (eg, 1050). Since the wxWidgets build of WebKit doesn't build against an SDK or explicitly set a deployment target, it is seeing MAC_OS_X_VERSION_MAX_ALLOWED set to 1056 where the Mac build sees 1050. This is why the checks that set BUILDING_ON_LEOPARD aren't working for you. I think we could rephrase the checks to accommodate building without an SDK and deployment target. Something like the following should do the trick: #if !defined(MAC_OS_X_VERSION_10_5) || MAC_OS_X_VERSION_MAX_ALLOWED MAC_OS_X_VERSION_10_5 #define BUILDING_ON_TIGER 1 #if !defined(MAC_OS_X_VERSION_10_6) || MAC_OS_X_VERSION_MAX_ALLOWED MAC_OS_X_VERSION_10_6 #define BUILDING_ON_LEOPARD 1 #endif I hope this clears things up. Let me know if you have any questions! - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Curl Cookie Handling
Hi Julien, On Feb 10, 2009, at 7:08 AM, Julien Chaffraix wrote: Hi Kevin, Is this patch still valid, i.e. not made obsolete by another approach? As far as I know, there is no work towards storing the cookies inside the database as it is done in Firefox. Furthermore I know no work in cURL toward exposing the cookies so that we could add / remove / update them simply in our database. This patch may be a bit special because it is not really cURL specific. The only dependency to cURL is a method to parse a date (the 'max-age' field), which I found later is already in JavaScriptCore and would need to be exported to WebCore and maybe need to be adapted. Thus it could be a base toward a cross-platform cookie implementation. I do not know if it would be ok for all ports to replicate their network library's cookie engine. Well, each port could of course decide for themselves. I know wx would like to use this. :-) I wonder if the GTK or other ports are also interested? Maybe they should voice their support if so. Also, was it a complete patch (sans any bugs, of course) for cookie support using SQLite? I could only test it using wx right now but I would definitely be interested in using the SQLite approach. It is a complete patch in the sense that it stores and fetch the cookies from the database. About the bug-free part, we have an answer in this thread I guess :-) Basically I could not find a test suite for cookies to validate the approach when I started so I tested it with real world websites (mostly google app suite, yahoo, mapquest and a few other sites) but it did not get the testing it deserves and I will not hide it. Yes, I did look at your patch earlier but I myself wasn't confident that I'd know how to properly test cookie support, so I hoped someone more knowledgeable would step in. :( To get it moving, I think a rewrite is necessary because I made tons of small mistakes (I started as a contributor at that time and did not know the code and coding conventions as I do now) that could be more easily tackled by a rewrite. It will also need a test suite to fully valide the changes. All in all, it means a lot of work that I am willing to do it *if* I see enough interest in a cross-platform cookie engine for WebKit. Well, knowing this project, I doubt you'll find anyone who would object to starting a series of unit tests for cookies. :-) From there, it is a matter of reworking your patch, but I can say if there is a test suite I can run that handles common usage, I'll feel a lot more comfortable reviewing your patch. I know someone a while back proposed a strategy for dealing with port enhancements that end up bit rotting in the review tree, whatever happened to that? Sometimes new feature patches cannot be broken down into smaller pieces, and I realize large patches tend to be intimidating especially to people who can't test them themselves, but there has to be some strategy for dealing with that so that important new stuff doesn't just sit in a patch tracker for months or years... I think you refer to the Gtk port here? IIRC the main issue for Gtk was validating the API which is not relevant here. That sounds familiar, I guess I mistook the discussion to be about port specific rather than API specific patches. Still, I think there ought to be some recourse when a patch submitter cannot find a willing reviewer after some long period of time. Thanks, Kevin Regards, Julien ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Curl Cookie Handling
Hi Julien, On Feb 9, 2009, at 7:23 AM, Julien Chaffraix wrote: Hi, I have Integrated the patch given in https://bugs.webkit.org/show_bug.cgi?id=14730 on webkit r36766 with additions on SQLITE db calls As you have seen this patch is not integrated and is a year old. As a result, it may have rotten (the code has changed and some assertions I made are not true anymore) and it was not tested much outside myself and a few people like you. So it is likely that there are some bugs (one was already mentioned on the bugzilla). Is this patch still valid, i.e. not made obsolete by another approach? Also, was it a complete patch (sans any bugs, of course) for cookie support using SQLite? I could only test it using wx right now but I would definitely be interested in using the SQLite approach. I know someone a while back proposed a strategy for dealing with port enhancements that end up bit rotting in the review tree, whatever happened to that? Sometimes new feature patches cannot be broken down into smaller pieces, and I realize large patches tend to be intimidating especially to people who can't test them themselves, but there has to be some strategy for dealing with that so that important new stuff doesn't just sit in a patch tracker for months or years... Regards, Kevin The patch does not work on www.facebook.com and results an inconsistent crashes / memory corruptions. Here is the snapshot of what valgrind has: [removed the backtrace] After a quick look at the code, it is likely that you are manipulating a deleted pointer. The cookie is taken directly from a cookieMap, which means that the cookieMap is not updated at some point when we release one of its pointer. However without further information, I cannot say more and you will have to debug yourself. Have you tried a DEBUG build as there are some assertions that could catch it earlier and help you tie the crash to one area of code? Also look at the different LOG information as they can help you. Regards, Julien ___ 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] What's up with the WX bot?
Hi Darin, Sorry about that, should be fixed now. I updated wxPython which broke the path to the wx-config used for the newer build, and that made it default to the wx built into Leopard. Thanks, Kevin On Jan 25, 2009, at 11:40 PM, Darin Adler wrote: The WX bot has been failing for a while (maybe weeks) with these errors: platform/wx/RenderThemeWx.cpp: In member function 'virtual bool WebCore::RenderThemeWx::paintButton(WebCore::RenderObject*, const WebCore::RenderObject::PaintInfo, const WebCore::IntRect)': platform/wx/RenderThemeWx.cpp:263: error: 'wxRenderer_DrawRadioButton' was not declared in this scope platform/wx/RenderThemeWx.cpp: In member function 'virtual bool WebCore::RenderThemeWx::paintTextField(WebCore::RenderObject*, const WebCore::RenderObject::PaintInfo, const WebCore::IntRect)': platform/wx/RenderThemeWx.cpp:286: error: 'wxRenderer_DrawTextCtrl' was not declared in this scope platform/wx/RenderThemeWx.cpp: In member function 'virtual bool WebCore::RenderThemeWx::paintMenuList(WebCore::RenderObject*, const WebCore::RenderObject::PaintInfo, const WebCore::IntRect)': platform/wx/RenderThemeWx.cpp:319: error: 'wxRenderer_DrawChoice' was not declared in this scope This looks like something that can only be fixed by doing something to the slave machine, perhaps installing a different version of WX? Until this is fixed this bot will always be red, and folks working on WebKit can't do anything about it. Can someone fix this? -- Darin ___ 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] Getting text alignment in editing mode?
Hi all, I'm working on adding HTML editing capabilities to the wxWebKit API, and I've gotten a lot of things working by exposing the edit commands, as well as providing a level of DOM wrapping for getting/manipulating attributes. One thing I've been unable to figure out, though, is how to get the text alignment(s) of a selection. The Align(Left/Center/ Right/Justify) commands do not provide a mechanism for reporting the state of those commands, and neither do I see an API in Editor, SelectionController, or DOMRange for it. Is there an 'official' way to get this information, or is it a matter of traversing the DOM and getting the info from each element myself? Thanks, Kevin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Fwd: Rename TypeInfo - JSTypeInfo?
Hi all, I sent this message to the mailing list yesterday, but it seems it never made it, so I'm resending. Kevin Begin forwarded message: From: Kevin Ollivier [EMAIL PROTECTED] Date: September 22, 2008 12:13:24 PM PDT To: webkit-dev@lists.webkit.org Subject: Rename TypeInfo - JSTypeInfo? Hi all, We're having a problem on the Windows version of wxWebKit where #include typeinfo is actually now including JavaScriptCore/kjs/ TypeInfo.h, which needless to say is not a good thing. ;-) I think this problem stems from the fact that we (the wx port, that is) don't use the 'framework' approach for JSC headers yet (and thus need JavaScriptCore/kjs on our include path), but I think in general it's good practice to avoid using system header names just for readability purposes. Does anyone see a problem with renaming TypeInfo to JS(C)TypeInfo, both header name and class? Thanks, Kevin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Fwd: Rename TypeInfo - JSTypeInfo?
Hi David, Okay, will do! Thanks, and sorry for the spam. I didn't see the message in my own list archives, which is why I thought it never made it. Now I just have to figure out what happened on my end. ;-) Kevin On Sep 23, 2008, at 9:32 AM, David Kilzer wrote: Hi Kevin, The original message did make it to the list, but no one replied. I think the best approach is to simply create a bug on bugs.webkit.org and attach a patch for review (since the wx port is apparently the only one feeling the pain right now :). Dave On Tue, 9/23/08, Kevin Ollivier [EMAIL PROTECTED] wrote: Hi all, I sent this message to the mailing list yesterday, but it seems it never made it, so I'm resending. Kevin Begin forwarded message: From: Kevin Ollivier [EMAIL PROTECTED] Date: September 22, 2008 12:13:24 PM PDT To: webkit-dev@lists.webkit.org Subject: Rename TypeInfo - JSTypeInfo? Hi all, We're having a problem on the Windows version of wxWebKit where #include typeinfo is actually now including JavaScriptCore/kjs/ TypeInfo.h, which needless to say is not a good thing. ;-) I think this problem stems from the fact that we (the wx port, that is) don't use the 'framework' approach for JSC headers yet (and thus need JavaScriptCore/kjs on our include path), but I think in general it's good practice to avoid using system header names just for readability purposes. Does anyone see a problem with renaming TypeInfo to JS(C)TypeInfo, both header name and class? Thanks, Kevin ___ 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] Rename TypeInfo - JSTypeInfo?
Hi all, We're having a problem on the Windows version of wxWebKit where #include typeinfo is actually now including JavaScriptCore/kjs/ TypeInfo.h, which needless to say is not a good thing. ;-) I think this problem stems from the fact that we (the wx port, that is) don't use the 'framework' approach for JSC headers yet (and thus need JavaScriptCore/kjs on our include path), but I think in general it's good practice to avoid using system header names just for readability purposes. Does anyone see a problem with renaming TypeInfo to JS(C)TypeInfo, both header name and class? Thanks, Kevin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Building WebKit WX port for Windows
Hi Javed, On Sep 3, 2008, at 2:12 PM, Javed Rabbani wrote: Hello everyone, I am trying to build WebKit WX port on Windows. The build process stops with a fatal error U1077 in cl.exe of Visual Studio 2005. The error code is 0xc135. Can anyone suggest possible cause of this behavior? I would appreciate if someone can guide me with proper way to build wx port on Windows using MSVC 2005. The WX Widgets version is 2.8.6. Even if someone has already built the port I would appreciate if the generated DLL/LIB can be shared so that I may continue with code debug. Thanks. Could you provide more details about where compilation stopped and what the exact error message you received was? Thanks, Kevin Regards, Javed Rabbani ___ 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] Mimetype for files loaded from disk?
Hi Mike and all, On Mar 16, 2008, at 10:26 PM, Mike Emmel wrote: In the curl backed some code uses file extensions to set the mime type for local files. I'm not sure css files are handled. They aren't, neither for GTK or wx implementation. Adding it for the wx implementation did solve the problem, and is obviously a much better approach. Thanks! :-) I'll go ahead and add the CSS mime type to GTK's MIMETypeRegistry code as well. Whether or not it's bitten by this bug, I think it'd be good to add it. I am still curious, however, if there is some difference in WebCore internally in terms of dealing with missing mimetype on Windows as opposed to Mac/Unix. If there is, and it is unintentional (e.g. it is intended only for Apple port on Win), it might be something that belongs at the WebKit level for each port. If it's intentional, I'm curious to know why we do things differently on Win. Thanks, Kevin On Sun, Mar 16, 2008 at 9:22 PM, Kevin Ollivier [EMAIL PROTECTED] wrote: Hi all, I've hit an issue with the wx port where HTML files that use @import url(file.css) will not load when the HTML and CSS file are on disk rather than loaded via the web. After tracking it down, I found that I could resolve the issue by having CURL set the file type for m_response to application/x-unknown-content-type, which enables the CachedCSSStyleSheet::canUseSheet test to pass, but I'm not sure this is the right approach. Another wrinkle to this issue is that this problem doesn't appear on the Windows wx port, only Linux/Mac. I'm fairly certain this discrepancy is not due to wx code, and so I was wondering how other ports (Apple's and otherwise) handle this issue. Is there some alternative approach to setting the mimetype explicitly, or is there some extension - mimetype mapping being used in some cases? Thanks, Kevin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Mimetype for files loaded from disk?
Hi all, I've hit an issue with the wx port where HTML files that use @import url(file.css) will not load when the HTML and CSS file are on disk rather than loaded via the web. After tracking it down, I found that I could resolve the issue by having CURL set the file type for m_response to application/x-unknown-content-type, which enables the CachedCSSStyleSheet::canUseSheet test to pass, but I'm not sure this is the right approach. Another wrinkle to this issue is that this problem doesn't appear on the Windows wx port, only Linux/Mac. I'm fairly certain this discrepancy is not due to wx code, and so I was wondering how other ports (Apple's and otherwise) handle this issue. Is there some alternative approach to setting the mimetype explicitly, or is there some extension - mimetype mapping being used in some cases? Thanks, Kevin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
Hi David, On Nov 12, 2007, at 1:19 PM, David D. Kilzer wrote: Kevin Ollivier [EMAIL PROTECTED] wrote: [...] The tricky part AFAICT would be XCode, though, because even if there is a scripted solution for this, it would probably need to be run on a Mac where we have access to AppleScript or some other scripting tool that can read and make changes to XCode projects... [...] Xcode project files are plain text as well. It's possible to update them via script (see WebKitTools/Scripts/sort-Xcode-project-file), but it requires a little more insight than just staring at the source. Right, in fact, I actually wrote a fair chunk of the XCode backend for Bakefile, so I do remember the basics of the format, although my memory is a bit hazy. :-) But the issue I saw with that approach is that adding a file doesn't just mean inserting a file entry, XCode uses UUIDs to refer to files and creates hierarchies of UUIDs to manage folder hierarchies and the like. So to add a file to a certain project folder, you'd have to retrieve the UUID of the parent folder the file is to be inserted into, along with any parent folders for that folder to know which PBXGroup in the project file you should insert the new file's UUID into, and I don't know how we can get that info without parsing the file and folder listing out of the XCode project file. It seems there would be similar issues with adding/ removing a folder from the project file. In short, I'm not sure we could get away with making those changes reliably without parsing at least some chunks of the project file, if not most of it. (WebCore.xcodeproj/project.pbxproj, for example, largely consists of file references and folder organization.) However, I have to admit I haven't seriously thought about the matter before today, so it's possible I'm missing or overlooking something important. Any ideas of how we could do this more simply? Thanks, Kevin Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Moving away from qmake
Hi Alp, On Nov 11, 2007, at 7:34 PM, Alp Toker wrote: The existing qmake-based build system is shared by the GTK+ and Qt ports. Until recently, this arrangement has not been too problematic for the GTK+ porters, with the idea being that qmake makes life easier for developers at the expense of a little inconvenience for users (in the sense of application developers rather than end users). However, it has recently become clear that qmake is actually making life more difficult for developers. It turns out that the existing qmake build system fails to do basic dependency tracking, leaving both developers and users with crashy builds, with the only way to get a stable build being to do a full clean and rebuild after every update. In the last week I've had to explain why people's builds are crashing to maybe half a dozen people on WebKit and GNOME-related channels. Mark and I have attempted to fix the dependency tracking a number of times, but we've both found qmake to be poorly documented, and our attempts to fix it ended up breaking the build even more in certain configurations. My informal attempts to get assistance from the Trolltech guys doing the Qt port have gone unanswered. I have no doubt that we would be able to fix these issues in a matter of minutes using a better understood or documented build system. Moreover, it has turned out that the qmake build dependency is more than just a little inconvenience for users. It makes the GTK+ port inaccessible to a lot of developers. Using anything but the latest Linux distributions, including cross-compilation frameworks like Scratchbox, you have to build the whole of Qt just to get qmake, which takes over an hour and almost a gigabyte of disk space for me. That's at least 5 times as long as it takes to build the whole of JavaScriptCore, WebCore and WebKit. Even in distributions that ship a recent binary of qmake, it is often bundled into the same binary package as the rest of Qt, making it a seriously large dependency. Now that the GTK+ port is getting attention from beyond a core team of developers, I think such a heavy build dependency is no longer acceptable. If either the Wx or Qt porters are willing to share a new build system with the GTK+ port, they should speak up now. We're willing to consider any build system that does not incur a huge dependency (ruling out qmake) and that is actively maintained and does not have verbose XML makefiles (ruling out Bakefile and Ant-like build systems respectively). cmake and autotools are fair game here, for example. If we cannot reach a conclusion, the GTK+ port will most likely go ahead and switch to autotools. Work has already started to provide an autotools-based build system at http://git.ndesk.org/?p=javascriptcore-modular An unforeseen benefit of the new build system is that it is modular, rather than monolithic, and has no dependency on GLib/GTK+ or any other framework. This means that it will now be possible to use JavaScriptCore as a standalone scripting engine independently of WebKit. I hope I've accurately summarised the thoughts of all those involved here. (It's quite unfortunate that we might end up contributing to the current proliferation of build systems, but I think it's fair to say that the qmake dependency is right now the biggest single issue holding back development and acceptance of the GTK+ port. If other ports are willing to compromise in the same way as we are on a shared solution, this proliferation can still be avoided.) Unfortunately, I don't see room to compromise on my end because neither autotools or cmake will meet my needs without a fair amount more effort on my part (effort I'd rather spend putting into improving wxWebKit itself), and I pretty much get all of the other benefits you mentioned are obtained by switching away from qmake, so there's not really any plus for me. Honestly, I find the Bakefile build system to not be very verbose at all thanks to its use of templates, which allow me to group together settings needed by various components and reuse them easily. The largest files are the *Sources.xml files, but those are very light on XML tags and are mostly text files, and are easy to update and maintain, IMHO. Over the past couple weeks, I in fact did a lot of refactoring on the build system and it was quite quick to do and I'm really pleased with the results. I haven't yet found a (cross- platform) tool that lets me be as productive as Bakefile does, which is the bottom line for me as my time is limited. The one downside to Bakefile is that it's newer than other systems and over time I've bumped into a few rough edges, but most of those have gotten fixed. Even with having to make a few temporary workarounds, though, I find it saves me a lot of time in other areas that more than makes up for it. Anyway, I won't press the matter; I admit I don't have a Unix
Re: [webkit-dev] Proof of Concept: NPAPI plugins in Qt/Windows
Hi Justin, On Nov 8, 2007, at 7:35 AM, Justin Haygood wrote: http://blog.justinhaygood.com/2007/11/07/youtube-in-qt-webkit-windows-only/ For more information, see the above blog post. Basically, it does it by (in a semi-clean way) utiziling the existing code for Windows plugins, which makes this method Windows specific. The requisite patch patches some other parts of the codebase for it to work as well, but for the most part. It actually works, as long you can see from the screenshot J. It needs work, but it’s a good proof of concept that it will work. Thanks for your work on this! :-) I think this approach would likely work for the wx port too, and I think in general it'd be useful to the project as a whole if we could split the plugin code into platform specific bits, and also the core code for Win/Mac/GTK (or X11?) like this, as obviously the plugins themselves are passing around native data structures rather than the ones the ports use. This way all the ports can share the core engine code and only have to implement the front end and do any necessary data type conversions, etc. BTW, one thing I noticed about your patch - it seems to remove and then re-add FrameLoaderQt.cpp (or else, whitespace or something else changed throughout the entire file). Was this intentional? Regards, Kevin Plugins tested and confirmed “working”: Flash Player 9 Quicktime 7 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WTF license terms
Hi all, I haven't contributed all that much to WTF (yet? ;-), but I wanted to say I'm certainly fine with any code I wrote being moved to the BSD license as well. Kevin On Nov 6, 2007, at 3:04 PM, George Staikos wrote: On 6-Nov-07, at 3:54 AM, Geoffrey Garen wrote: Mainly I'd like to hear if any major contributors would have a problem with this move. I guess I'll sound like a bit of a shill here, but: I contributed to the WTF code and I wouldn't mind moving it to a BSD license. I approve moving all of my WTF contributions to BSD license. -- George Staikos KDE Developer http://www.kde.org/ Staikos Computing Services Inc. http://www.staikos.net/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Page, Frame, FrameView and FrameTree clarification needed
Hi Adam, On Jul 16, 2007, at 9:52 AM, Adam Roben wrote: [snip] I think there are probably two approaches to implement it: 1.) Have one GdkWindow for the main Frame of the Page + Resource friendly + z-order would always be right - Scrolling would need to be manually handled by ScrollView (e.g. similiar to the Qt port) - Complex handling of coordinates - Complex to get right at the beginning (clipping, translation of the GraphicsContext) - Embedding real Platform::Widget will be more tough. 2.) Have one GdkWindow for each FrameView + Easy and understandable - Need to get passing expose events to children right to have the z-Order. - Need to make ScrollView::update update the right (outermost) region - Would only work when we have non-transparent overlapping Frame's (does this apply?) 3.) What did I miss? Answers and pointers to manual Frame tests would be appreciated. I'm tempted to go with the 2nd option. I think you'll have a much easier time getting things right in the end if you go with the first option (one native widget (GdkWindow) per Page, not per Frame). Otherwise you'll have lots of trouble getting painting to happen in the correct order (imagine an absolutely positioned div in the main frame that overlaps a subframe -- the subframe needs to paint after everything in the main frame *except* for the div). Are there test cases in DumpRenderTree, etc. that can be used to explore how well a port handles conditions such as these? I'm actually using #2 for wx and so far it's been working quite well, but I honestly don't know how it handles some of those cases you mentioned, and I'd like to be able to verify that it works (or doesn't, as the case may be... ;-). Thanks, Kevin PS: Yes, we should get DumpRenderTree working for Gtk+ and should look into validating test results... Yes, that would be good :-) -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: reorganization of WebKitTools/Scripts
Hi Adam, On May 20, 2007, at 12:39 PM, Adam Treat wrote: Hi, Currently the build, run and debug scripts in WebKitTools/Scripts are a mashup of scripts for the various ports. Most of the scripts are written in perl, but a few are bash scripts. Some of them use common functions, but not all and not all in the same way. I'd like to propose a reorganization so that all the ports can share common defines and functions as well as a common build directory root. Specifically: 1. Add a dir for each port so we'd have Scripts/mac, Scripts/qt, Scripts/gdk for port specific scripts where the common defines and functions would live in the Scripts directory proper. For the wx port, we have only one port-specific script (2 if you count regenerate-makefiles), and I wasn't aware that there were many other port-specific scripts in the WebKitTools/Scripts dir. Personally, I'm fine either way, but if each of the subdirs have 1-2 scripts max, it might be simpler just to leave things as they are. Of course, I think a README with a brief summary of what each script does would probably be very helpful in either case. 2. Specify command line options for all scripts which would invoke the proper port specific script. That or we set a standard ENV variable that the scripts can use to invoke the port specific scripts. ie: build-webkit (--mac|--qt|--gdk) OR make build-webkit script to read $(WEBKIT_PORT) env var... The latter (or both) would be preferable to me, as it would also make other scripts (such as run-javascript-tests and install-*-extras) able to handle port-specific issues (e.g. it would know how to get the proper configuration dir from webkitdirs.pm). On the wx-port- alpha branch, I currently do both - use build-webkit --wx to build, then have builders set a WXWEBKIT environment variable which is read by webkitdirs.pm so that it can be 'wx' aware when running other scripts. Of course, WEBKIT_PORT would be a much better solution to this. 3. Make bakefiles ports respect WebKitBuild dir... and so on... This has been done actually for wxWebKit on the wx-port-alpha branch as part of those changes. I could prepare a patch for this (at least the bits that affect all Bakefile ports), but I don't have the GDK port running to test against, so I'd need help there. Regards, Kevin Comments? Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Patch for notImplemented() macros
Hi Darin and all, On Apr 9, 2007, at 3:12 PM, Darin Adler wrote: On Apr 8, 2007, at 3:38 PM, Kevin Ollivier wrote: One other issue I wanted to bring up that I've run into is an issue with needing the notImplementedGdk() macro to be defined even though we're not using the GDK port, as we use the CURL downloader. We've hacked around it in our sources for now, but IMHO we'll have to either have both notImplemented() and notImplementedGdk() available to the GDK port, or remove the need for a separate notImplementedGdk() macro if that's possible. Also, there's a lot of duplication of notImplemented() in various sources anyway, so I thought it might be worth bringing up the idea of consolidating all those definitions into a header somewhere (Assertions.h?). As it seems different ports might want to implement it different ways, we can use #If PLATFORM(XYZ) blocks to allow alternative definitions. What do you guys think? Do you see doing it this way causing any problems for any of the ports? If you agree, any suggestions on where notImplemented() should go? I think we should add WebCore/platform/NotImplemented.h and use the #if PLATFORM(XYZ) approach. Well, it's taken me a little while, but I've finally submitted this as a patch in Bugzilla. The bug report is here: http://bugs.webkit.org/show_bug.cgi?id=13699 Since this mostly affects the GDK and Qt ports, which I'm not setup to build, I'd appreciate it someone setup for those ports could give this patch a try. Regards, Kevin -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
