On Mon, Feb 11, 2013 at 1:41 PM, Kevin Ollivier <kev...@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 >> <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 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 machine s > 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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
