[webkit-dev] Is the wxWidgets port maintained?

[Kevin Ollivier]

On Feb 11, 2013, at 2:01 PM, Martin Robinson wrote:

> On Mon, Feb 11, 2013 at 1:41 PM, Kevin Ollivier <kevino at 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 FileName<portName>.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.
> 
> 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