On 6/10/05, Maciej Stachowiak <mjs@apple.com> wrote:

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.

Yes, that makes sense. The issue indeed is to keep these two build systems in sync, especially in cases where a developer does not have access to a Mac platform for updating the Xcode projects... The qmake tool from Trolltech also used to be able to export from a canonical build-rule format to Makefiles and Xcode project files (at least when I worked on the Mac side over at Trolltech, don't know how well they support XCode 2.0/2.1 today.. might work fine). So that's an option. qmake and SCons are examples of starting from a meta-level description and build platform-dependent Makefile and project environments. I don't know of any good and reliable ways to convert back and forth between GNU automake and XCode projects. --Kent PS: I'm looking at porting WebCore on top of DirectFB/LiTE (www.directfb.org), been working on LiTE recently to make it a very quick way to build toolkits on top of DirecDB, especially for embedded systems, and WebCore/KWQ would be a nice test ground for it, would be interesting to look at Qt code for the conversion part, too -- been a while since I last hacked Qt.

On 6/10/05, Maciej Stachowiak <mjs@apple.com> wrote:

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.

Hmm, CF Lite (Core Foundation Lite)? The only issue I see is the license that is neither BSD nor LGPL for the CFLite sources... But those could then be ported across various platforms, already working for Linux), and the data structures and so forth are nice, string classes that support Unicode, unless there's too much overlap between KQW and CFLite... --Kent

On Jun 10, 2005, at 8:59 AM, Kevin Ollivier wrote:

IMHO, looking at the sources, it's probably an easier task to remove CF from common bits of KWQ and JSCore (as there isn't a whole lot) than it is to have someone maintaining CFLite cross- platform and being sure it builds on Windows as well, etc. There's lots of CF code in the platform-specific part, but that's closely tied with Cocoa, so we had to re-implement those bits anyways, and it was easier just to use our own APIs for that. So far, that's been our experience.

I agree completely with this. When we've talked about this internally in the Safari and WebKit team at Apple, we've had this approach in mind. It's great to use CF code when it's about connecting to the platform, but I believe we can remove use of CF in common parts easily without causing any troubles on the Mac OS X platform. -- Darin

On 6/11/05, Michael Maibaum <mike@maibaum.org> wrote:

I just wanted to point out the efforts at OpendDarwin on libFoundation - http://libfoundation.opendarwin.org/ I know it has at least partial NSString support and is being built and tested against the Apple Foundation API specification. I have no idea if this is actually useful at this point, but ...

It's not. But don't let that stop you contributing! :-) -- Finlay

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@opendarwin.org http://www.opendarwin.org/mailman/listinfo/webkit-dev