[webkit-dev] Is the wxWidgets port maintained?

[Martin Robinson]

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. 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.

--Martin