[webkit-dev] Is the wxWidgets port maintained?

[Dirk Pranke]

On Mon, Feb 11, 2013 at 1:41 PM, Kevin Ollivier <kevino at theolliviers.com> wrote:
> Hi Martin,
>
> On Feb 11, 2013, at 12:47 PM, Martin Robinson wrote:
>
>> On Mon, Feb 11, 2013 at 11:27 AM, Kevin Ollivier
>> <kevino at 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 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.
>
> 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.
>

I have to admit, I thought waf was more like scons and less like cmake
and gyp, i.e., I thought it was a portable build system rather than a
meta-build system (and had never looked at it in detail accordingly).
I am taking another look at it now :)

-- Dirk