[webkit-dev] Porting Gtk+WebCore

[Kevin Ollivier]

Hi Maciej,

On Jun 10, 2005, at 12:02 AM, Maciej Stachowiak wrote:

[snip]

> This is a question that some of us on the Safari/WebKit team have  
> thought about, but we're not sure which way to go yet. As I see it,  
> there's two basic options:
>
> A) Use autotools on every possible platform, even Mac OS X. We used  
> to do this way long ago towards the start of the project, and over  
> time we converted to Xcode because of all the nice things we get  
> from it. So in some ways this would be more of a pain for the  
> existing WebKit developers at Apple.
>
> B) Use Xcode projects on OS X, and autotools for ports to more  
> traditional unix systems (Linux, FreeBSD, etc). The major downside  
> to this is that to make any kind of build change (even just adding  
> a new file), you would have to do it twice. And not only that you  
> would really need a Mac even if that is not your primary dev  
> platform, since the Xcode project file format is not really human- 
> editable.
>
> We're really not sure yet which of these is better. I think it  
> might be best to start with B, and consider converting to A someday  
> if there are enough active developers on non-Mac platforms.

What we're using for wxWebCore is a program called Bakefile (http:// 
bakefile.sf.net). It is already being used to generate the wxWidgets  
makefiles, and as you may be aware, wxWidgets has a massive build  
system and supports a large variety of different compilers and  
platforms. So there's some proof that this software works. :-) The  
only compilers/tools I can think that aren't "officially" supported  
are (unfortunately) XCode, and CodeWarrior. We manually maintain  
makefiles for those compilers at the moment. However, a version of  
Bakefile with basic XCode support does exist in their CVS, so it's  
not as if no one is working to resolve these issues.

The nice part about this system is, while it's multiplatform, most  
developers can just work with the generated makefiles for their  
compiler/platform and don't have to install additional tools. You  
only need Bakefile if you want to regenerate makefiles from the  
original Bakefile.

I think this would be ideal for the multiplatform components because  
you can create a Bakefile template for the multiplatform bits with  
all the common defines, sources, etc. that should build everywhere,  
and each port can simply include that Bakefile into their own port.  
That way, they can choose which compilers/platforms they support, and  
build makefiles for those, while at the same time whatever they  
choose they don't have to write a separate makefile to build the  
cross-platform bits.

Here's our wxWebCore Bakeilfe. As you can see, it's an XML-based script:

http://svn.berlios.de/viewcvs/wxwebcore/wxwebcore/trunk/wxwebcore.bkl? 
rev=190&view=markup

I tried building our JSCore on Windows the other day, and it took  
literally just a couple minutes to modify the bakefile not to build  
WebCore sources and create a full-fledged MSVC DSP/DSW project. Of  
course, MSVC doesn't have access to "stdint.h" and there's the  
threading issues that others have mentioned, so it didn't build out  
of the box. ;-/ Yet. ;-)

>
>> KWQ side of WebKit is also heavliy OSX dependent. Any ideas how to  
>> make this different? Especially refactoring the bridge and  
>> generalizing the KWQ widgets to support Carbon, Gtk+, Windows  
>> widgets needs a bit of thought.
>>
>
> There's really several different things in the KWQ directory:
>
> 1) Fairly platform-agnostic replacements for things like data  
> structures and QString (QDict is one exception here, but we'll be  
> changing that to not rely on CFDictionary any more). These could  
> just be used for any platform that uses KWQ instead of the real Qt.
>
> 2) Completely platform/toolkit specific implementations of the Qt  
> widgets. We'd need separate implementations of these per port - I'm  
> not sure how much of the code if any is shareable across ports.

In my experience, not much. I don't think it's really worth going  
through these files and trying to separate out common bits.

> 3) Bridging logic, for binding to an API wrapper layer. This is  
> mostly KWQKHTMLPart and WebCoreBridge. Unfortunately these have
>
> 4) Bridging to system APIs that are implemented in WebKit, stuff  
> like WebTextRenderer.m. This might not be needed at all for other  
> ports. I'm not really sure.

 From looking at GTK+WebCore and our own port, I personally think  
each port needs to make that decision separately, and it's fairly  
dependent on what the API being ported to already supports. At first  
I wanted to mimic the WebCore API simply to make merging/porting code  
changes a bit easier, but I found that wx and Cocoa/ObjC are of  
course different toolkits and different solutions should sometimes be  
used for each. So sometimes there is overlap, sometimes not, but I  
think it's fair to say classes like that won't always be needed for  
other ports or may be implemented in a very different manner.

I think pulling out the common bits and changing them to .cpp files  
(and many can just have their filename changed :-) would be a great  
start towards easing maintenance of the various
ports. You could probably just add a "common" subdirectory under kwq,  
as well as one for each port "cocoa", "gtk", "wx"... In any case, the  
less stuff we have to be worried about getting out of sync, the better!

Thanks,

Kevin

>
>> I think the main issues are defining how the WebKit portability  
>> project relates to the Apple's WebKit. Anyway, I can happily help  
>> porting the Gtk+WebCore. It'd be great even if the project was  
>> just hosted at opendarwin, because then it might attract more  
>> people actually working on it.
>>
>
> That would be awesome. We'd definitely be happy to host it here,  
> and we would do our best to encourage more contributors.
>
> Regards,
> Maciej
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at opendarwin.org
> http://www.opendarwin.org/mailman/listinfo/webkit-dev
>