Re: [webkit-dev] Building WebKit on windows using Cairo

[Daniel Zucker]

Hi Bahaa,

I said earlier that I would update the wiki with updated build instructions,
but I haven't yet had time.  Sorry.

In the meantime, try this:
-follow current wiki instructions
-manually apply patch in https://bugs.webkit.org/show_bug.cgi?id=18435
-manually apply patch in https://bugs.webkit.org/show_bug.cgi?id=18471

This should work.  However, I haven't had time to look at the code in the
last 1-2 weeks, so it is not confirmed.

Let me know how it goes.

Best,
Dan



On Mon, May 5, 2008 at 9:25 AM, Gmail (bahaazaid) <[EMAIL PROTECTED]>
wrote:

>  Hi,
> I want to use WebKit in my application on windows, I think it's much
> better than Gecko specially in my problem domain.
> I want to build its Cairo port on windows because I want to use %100 open
> source code in my project.
>
> I followed the instructions in the WebKit wiki
> http://trac.webkit.org/wiki/BuildingCairoOnWindows but I couldn't build
> it.
> I faced many compilation errors about cURL and others.
>
> Please, can anyone help me to build it?
>
> Thanks
>
> --
> *Bahaa Zaid*
> Software Engineer
> Arx ICT
> http://arxict.com
> [EMAIL PROTECTED]
> +20 10 298 9129
> My Calendar
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Where does WebKit end and Safari begin on Windows?

[Daniel Zucker]

Hi Paul,

>
> You correctly determined that the current build instructions are out of
> date.  Yes, some updates are required.
>
> I have been planning to update the wiki page with enhanced directions on
> how to build.  Please wait and I will update it over the next couple of
> days.
>
> Best,
> Dan
>
>
> On Fri, Apr 25, 2008 at 9:59 AM, Paul Monson <[EMAIL PROTECTED]>
> wrote:
>
>> Should following the directions for building WebKit using Cairo and
>> CURL work?  I tried to build webkit yesterday with updated source code based
>> on the wiki page directions and I have 39 errors.
>>
>> My company is evaluating using WebKit on Windows CE and as a first step I
>> am trying to build webkit on Windows XP without any non-redistributable
>> Apple libraries.
>>
>> Best regards,
>> Paul
>>
>>  --
>> Date: Fri, 25 Apr 2008 08:00:24 -0700
>> From: [EMAIL PROTECTED]
>> To: [EMAIL PROTECTED]
>> Subject: Re: [webkit-dev] Where does WebKit end and Safari begin on
>> Windows?
>> CC: webkit-dev@lists.webkit.org
>>
>>
>> Hi Patrick,
>>
>> Glad to hear the positive feedback on Safari/WebKit performance on
>> Windows.
>>
>> IMHO, this performance is due much more to the WebKit portion--much less
>> to the Safari layer.
>>
>> Please note that if you would like to use WebKit on Windows, the
>> mainstream version requires non-redistributable Apple libraries.  This means
>> you cannot use it in a commercial application.
>>
>> However, there is an effort underway to replace the Apple libraries with
>> opensource alternatives.  See
>> http://trac.webkit.org/projects/webkit/wiki/BuildingCairoOnWindows.  This
>> should give you a solution that you can use with your commercial
>> application.
>>
>> Best,
>> Dan
>>
>> On Fri, Apr 25, 2008 at 7:48 AM, Patrick Gostovic <[EMAIL PROTECTED]>
>> wrote:
>>
>>  Hi List.
>>
>> My company is developing an in-store kiosk application using DHTML/Ajax,
>> etc.  It has to be Windows for a variety of reasons.  The goal is to have a
>> nice looking interface with lots of tasteful, fancy animations.  We were
>> initially planning to use Internet Explorer to maximize hardware peripheral
>> integration (i.e. card reader, proximity sensor, etc.) and most kiosk
>> management software vendors assume IE; but needless to say IE's performance
>> is suboptimal.  Firefox is much better.  But Safari blows them all away in
>> every respect – JavaScript performance, rendering speed of animations,
>> overall prettiness, etc.  My big question… How much of Safari's prowess can
>> be attributed to WebKit?  I ask because I have tried both Adobe Air's WebKit
>> port and the latest QT QWebView widget and I just don't see the same results
>> – they are both good, but not nearly as smooth and pretty.  Why is Safari so
>> much better, and is there any way to get that Safari experience in locked
>> down fullscreen mode?
>>
>> Thanks for indulging.
>>
>> Patrick
>>
>> p.s. apologies if this is not the appropriate forum for this question J.
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Where does WebKit end and Safari begin on Windows?

[Daniel Zucker]

Hi Patrick,

Glad to hear the positive feedback on Safari/WebKit performance on Windows.


IMHO, this performance is due much more to the WebKit portion--much less to
the Safari layer.

Please note that if you would like to use WebKit on Windows, the mainstream
version requires non-redistributable Apple libraries.  This means you cannot
use it in a commercial application.

However, there is an effort underway to replace the Apple libraries with
opensource alternatives.  See
http://trac.webkit.org/projects/webkit/wiki/BuildingCairoOnWindows.  This
should give you a solution that you can use with your commercial
application.

Best,
Dan

On Fri, Apr 25, 2008 at 7:48 AM, Patrick Gostovic <[EMAIL PROTECTED]>
wrote:

>  Hi List.
>
>
>
> My company is developing an in-store kiosk application using DHTML/Ajax,
> etc.  It has to be Windows for a variety of reasons.  The goal is to have a
> nice looking interface with lots of tasteful, fancy animations.  We were
> initially planning to use Internet Explorer to maximize hardware peripheral
> integration (i.e. card reader, proximity sensor, etc.) and most kiosk
> management software vendors assume IE; but needless to say IE's performance
> is suboptimal.  Firefox is much better.  But Safari blows them all away in
> every respect – JavaScript performance, rendering speed of animations,
> overall prettiness, etc.  My big question… How much of Safari's prowess can
> be attributed to WebKit?  I ask because I have tried both Adobe Air's WebKit
> port and the latest QT QWebView widget and I just don't see the same results
> – they are both good, but not nearly as smooth and pretty.  Why is Safari so
> much better, and is there any way to get that Safari experience in locked
> down fullscreen mode?
>
>
>
> Thanks for indulging.
>
>
>
> Patrick
>
>
>
> p.s. apologies if this is not the appropriate forum for this question J.
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Idea for comments: Using Git to manage some WebKit platform ports

[Daniel Zucker]

Hi Ryan,

Thanks for forwarding to the list.  I meant to send it there originally, but
it accidentally got sent only to you.

One additionally point is that by hosting ports with the main webkit trunk
then all ports are treated equally by WebKit policy concerning review,
committers, etc.

For individually hosted Git ports, this is not the case.

Best,
Dan

On Fri, Apr 11, 2008 at 9:37 AM, Ryan Leavengood <[EMAIL PROTECTED]>
wrote:

> Daniel only responded to me personally (the strange way this list
> works I guess), so hopefully he won't mind a public response:
>
> On Fri, Apr 11, 2008 at 12:21 PM, Daniel Zucker <[EMAIL PROTECTED]> wrote:
> > Perhaps one possible negative to this is that there would now be
> definite
> > resource requirements to host a port.  Specifically, a new port would
> need
> > to both host a git server (requiring hardware and bandwidth),
>
> This is a reasonable point, but fortunately there are places like
> http://gitorious.org/ and http://github.com that can host open source
> Git repos for free.
>
> > and also actively migrate patches to this port as they are developed.
>
> True, but *someone* would have to do that work either way, and it is
> probably a better use of resources to have the person with a real
> stake in and understanding of the port doing the work rather than some
> of the other WebKit developers who have deeper concerns in the main
> codebase and the larger ports.
>
> > In the case of ports integrated directly into the main WebKit trunk,
> neither
> > of these are required:  the port code would be hosted at webkit.org, and
> no
> > one needs to actively port patches over since they are maintained in the
> > main webkit trunk.
>
> See above point about maintaining ports.
>
> > Personally, I think the increased resource requirements in the case
> where
> > new ports all have their own git repository would make it difficult for
> > people without a lot of time or money to do new ports.
>
> Time will be required either way, believe you me ;)
>
> Money shouldn't be a big problem because of the above services. Plus
> if a port really becomes that popular it could always be merged back
> into the main repo.
>
> Regards,
> Ryan
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] wx/Gtk+ and Network backends

[Daniel Zucker]

Hi Holger,

Another customer for the CURL backend used by Gtk+ and wx is the
"Windows-Cairo" or "Native Windows" version.

Brent Fulgham and I have been working on some patches to use this CURL code
in this Windows version.  When all the patches are landed (if not already
now) this CURL code will be fully functional on Windows.

Being lazy programmers (speaking for myself at least :)), we would like to
continue to leverage the CURL work from other ports as much as possible.  We
look forward to continue sharing the current CURL code as well as add the
upcoming support for authentication, web download, and possibly cookies.

Cheers,
Dan

On Fri, Mar 21, 2008 at 10:25 AM, Holger Freyther <[EMAIL PROTECTED]> wrote:

> Hey,
>
> I'm a bit alarmed by the wild growth of network backends for the Gtk+
> port,
> the pending patches in the bugtracker and the duplication of things that
> are
> ahead and have already started.
>
> Currently we have a CURL backend shared by Gtk+ and wx. The good thing is
> it
> is shared between the two ports. The bad things are. We have no GEventLoop
> integration on Gtk+ and will poll curl with a timer. It lacks uploading of
> files (a good looking patch is in the bug tracker), it lacks cookie
> handling
> (also a good patch in the bug tracker), authentication is missing as well.
>
>
> Recently a libsoup based backend got added. I assume it has event loop
> integration, from blogs I know that upstream has looked into cookies.
> Which
> probably leaves authentication, cookie management, form uploads, sync
> loading
> of resources open as well.
>
>
> Mike just proposed another CURL backend that will fix the above event loop
> handling (from what I see).
>
>
> The first bugs for CURL already have attachments like "Do this for SOUP as
> well". So the duplication of effort already started.
>
>
> What I like to have answered/see is:
>- Is it a strict requirement that Gtk+/WX share the same backend?
> (I think
>  not)
>
>- Can we please just use one backend for the Gtk+ port? We do not
> use DRT in
> a sane way so it will be a hell to maintain three backends and make sure
> that
> all of them have the same amount of features. E.g. the first consequence
> would be to have three build bots running for the three backends..
>
>
> So please before wasting more time on implementing the same things for
> different backends let us wotk on one together. I do not care if it is
> curl+glib, soup, neon...
>
>
> z.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Windows Cairo Update

[Daniel Zucker]

The patch to remove CFNetwork and instead use Curl is available here:

http://bugs.webkit.org/show_bug.cgi?id=17730

Please try it out and let me know what you think.

Cheers,
Dan

On Fri, Mar 7, 2008 at 6:33 PM, Brent Fulgham <[EMAIL PROTECTED]> wrote:

> Today was a busy day for Windows Cairo commits.  The gigantic Visual
> Studio project file merge has been completed, and at the moment we are down
> to a single required patch (http://bugs.webkit.org/show_bug.cgi?id=17484)
> to build a Cairo-backed WebKit.
>
> A second patch (http://bugs.webkit.org/show_bug.cgi?id=17715) causes
> WinLauncher to be built as part of the normal build process.  This is not
> required, but I find it helpful as it's currently the only thing that
> actually runs with the Cairo-backed DLL.  Safari will not run with the
> Cairo-based build, and is less likely to work as time passes due to the
> removal of various Apple-specific routines from the sources that Safari uses
> for various aspects of its operations.
>
> I recently found that CoreGraphics is not entirely gone; there are a few
> calls to wk* functions (defined in the libWebKitSystemInterface*.a files)
> that in turn make use of CoreGraphics.  I am working on a patch to remove
> these functions, at which point we will be totally separated from
> CoreGraphics.
>
> I understand that Dan Zucker has made some good progress on removing
> CFNetwork in favor of Curl; hopefully we'll all get our hands on those
> changes soon.
>
> Thanks,
>
> -Brent
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Problems with svn-create-patch on Vista

[Daniel Zucker]

Has anyone successfully run svn-create-patch on Vista?

I am seeing errors like:
 17 [main] svn 1408 child_copy: linked dll data write copy failed,
0x877000.
.0x8770B0, done 0, windows pid 2812, Win32 error 87
svn: Can't start process 'diff': Resource temporarily unavailable
 17 [main] svn 5324 child_copy: linked dll data write copy failed,
0x877000.
.0x8770B0, done 0, windows pid 4888, Win32 error 87
svn: Can't start process 'diff': Resource temporarily unavailable
 16 [main] svn 3092 child_copy: linked dll data write copy failed,
0x877000.
.0x8770B0, done 0, windows pid 3208, Win32 error 87
svn: Can't start process 'diff': Resource temporarily unavailable
 17 [main] svn 2304 child_copy: linked dll data write copy failed,
0x877000.
.0x8770B0, done 0, windows pid 2988, Win32 error 87

This appears to be some sort of resource contention.   Sometimes the diff
runs correctly, and sometimes it fails with the error above.

The script runs successfully for me using the same source and setup on XP,
so I suspect this is a Vista problem.

Has anyone seen this before?  Any ideas how to fix?

Thanks,
Dan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WIN XP Build Error

[Daniel Zucker]

To add some more information:

In the past, I always had to run "d2u auto-version.sh" to get the build to
work.  If you don't do this the script won't run at all.

With the recent problem, the script does run (after running the above d2u
command), but seems to introduce some bad line ending in the resultant
autoversion.h file as indicated in the error below.

Cheers,
Dan

On Tue, Feb 26, 2008 at 12:50 PM, Daniel Zucker <[EMAIL PROTECTED]> wrote:

> Yes, I use TortoiseSVN.
>
> -Dan
>
>
> On Tue, Feb 26, 2008 at 9:36 PM, Brent Fulgham <[EMAIL PROTECTED]> wrote:
>
> > Are those of you experiencing the autoversion.h problem using
> > TortoiseSVN to retrieve the sources?
> >
> > -Brent
> >
> >
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WIN XP Build Error

[Daniel Zucker]

Yes, I use TortoiseSVN.

-Dan

On Tue, Feb 26, 2008 at 9:36 PM, Brent Fulgham <[EMAIL PROTECTED]> wrote:

> Are those of you experiencing the autoversion.h problem using TortoiseSVN
> to retrieve the sources?
>
> -Brent
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WIN XP Build Error

[Daniel Zucker]

Yes -- both debug and release.

Cheers,
Dan

On Mon, Feb 25, 2008 at 10:34 AM, Brent Fulgham <[EMAIL PROTECTED]> wrote:

> Are you guys seeing this if you build in Debug mode?
>
>
> On Mon, Feb 25, 2008 at 2:29 AM, Ivan Shusky <[EMAIL PROTECTED]> wrote:
> >
> > >  Hi,
> > >
> > > I am attempting to compile the latest WebKit code under Windows XP
> > > environment and there is this error message:
> > >
> > > -- Build started: Project: Interfaces, Configuration: Release
> > > Win32 --
> > > Performing Pre-Build Event...
> > > Creating Type Library...
> > > Processing ..\Interfaces\WebKit.idl
> > > WebKit.idl
> > > C:\WebKit\WebKitBuild\obj\Interfaces\Release\include\autoversion.h :
> > > error C4335: Mac file format detected: please convert the source file to
> > > either DOS or UNIX format
> > >
> > > I have tried many ways but failed to solve it. Is there any
> > > environment variable or some setting that I have missed?
> > >
> > > Thanx in advance for your help.
> > >
> > > Best,
> > > Ivan
> > >
> >
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] WIN XP Build Error

[Daniel Zucker]

Hi Ivan,

I am seeing this bug also (on Vista).  I suggest filing a bug report on it.

Here is a workaround:
1.  Manually fix the line endings in
C:\WebKit\WebKitBuild\obj\Interfaces\Release\include\autoversion.h using
your favorite editor.  There is another autoversion.h file (can't remember
the location off the top of my head now), that you will have to fix as well.
2.  Disable C:\WebKit\WebKitLibraries\win\tools\scripts\auto-version.sh so
that the fixes you did in step 1. are not clobbered.
3.  Build as normal

This should get you building.

I noticed that auto-version.sh changed on Feb. 12-13, so I suspect this is
where the problem was introduced.  I'm not sure why more people aren't
seeing this.

Hope this helps.

Cheers,
Dan

On Mon, Feb 25, 2008 at 2:29 AM, Ivan Shusky <[EMAIL PROTECTED]> wrote:

> Hi,
>
> I am attempting to compile the latest WebKit code under Windows XP
> environment and there is this error message:
>
> -- Build started: Project: Interfaces, Configuration: Release Win32
> --
> Performing Pre-Build Event...
> Creating Type Library...
> Processing ..\Interfaces\WebKit.idl
> WebKit.idl
> C:\WebKit\WebKitBuild\obj\Interfaces\Release\include\autoversion.h : error
> C4335: Mac file format detected: please convert the source file to either
> DOS or UNIX format
>
> I have tried many ways but failed to solve it. Is there any environment
> variable or some setting that I have missed?
>
> Thanx in advance for your help.
>
> Best,
> Ivan
>
> --
> Express yourself instantly with MSN Messenger! MSN 
> Messenger
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Regarding WebKit Support Libraries

[Daniel Zucker]

Hi Alp,

I am happy to contribute to this ongoing effort to make a Windows version of
WebKit free from Apple libraries.

I would prefer to wait until there is consensus from the community on the
best way to move forward, so that my coding effort is not wasted.

Cheers,
Dan

On Feb 17, 2008 11:27 AM, Alp Toker <[EMAIL PROTECTED]> wrote:

> Daniel Zucker wrote:
> > Hi Alp and Brent,
> >
> > My vote is to use Wininet.
>
> Hi Daniel,
>
> You can register your vote by writing and offering to maintain a WinINet
> http backend.
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Regarding WebKit Support Libraries

[Daniel Zucker]

Hi Alp and Brent,

My vote is to use Wininet.

This is because my objective is to eventually support a WinCE version.
Wininet is used in both Win32 and WinCE, so it is a convenient choice from
this point of view.

CURL would be OK if it could be easily ported to WinCE.  I haven't looked
into that, so I don't know the difficulty.  But, I suspect it is
non-trivial.  Also, it would have the downside of requiring extra code which
increases the static application size.  (Static application size is an
important consideration for mobile use cases).

So, I vote for using Wininet.  There was Wininet support in the codebase
earlier.  I believe this could be resurrected without too much trouble.

Cheers,
Dan

On Feb 15, 2008 5:33 AM, Brent Fulgham <[EMAIL PROTECTED]> wrote:

> Hi Alp,
>
> On Feb 14, 2008, at 2:05 AM, Alp Toker wrote:
>
> > Brent Fulgham wrote:
> >> In the medium term, I will probably end up ripping out the
> >> CFNetwork code to replace with native windows calls, though it
> >> would be nice to avoid this needless work.
> > The CURL http backend used by the GTK+ and Wx ports works on
> > Windows, though it's not as complete as CFNetwork. It could do the
> > job till the CFNetwork issues are resolved.
>
> In light of Apple's recent notification (today) that CFNetwork would
> no longer be available as open source, I think we've got to shift to
> the CURL back-end.  There are really only three options I see:
>
> 1.  If license allows, take the existing APSL CFNetwork sources and
> attempt to use it.  Downsides:  lots of work to achieve existing
> features.  No real upside.
> 2.  Implement native WinInet versions of features from CFNetwork.
> Downsides:  Single-platform, minimal reuse.  Not much assistance to
> find problems.
> 3.  Use CURL library.  Benefits:  Assist in CURL development, share
> code with other project targets (read:  I get to bug Alp when I have
> problems).  Downside:  Mostly just the manual effort of
> conditionalizing the CFNetwork code.
>
> Of these, the only one that really seems desirable to me is the CURL
> back-end.
>
> > CFNetwork is integrated into the Win port (consider how HTTP
> > resource errors are handled and passed up to the UI) so swapping it
> > out for something else may have some unfortunate maintenance
> > overhead (ifdefs, more platform splits, and associated build system
> > changes).
>
> Agreed, but I don't see that we have much choice at this point.
>
> -Brent
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Pulling together on WebKit Mobile

[zucker]

My vote would be to use #if PLATFORM(XX) to wrap relevant source files,
and to create new Configurations to choose which libraries to link to.  I
think this is the simplest while still providing the functionality we
need:

-we must have the ability to link to different libraries for different
builds, so that we can not link with, for example, CoreGraphics or Cairo
-we do not want to have to maintain multiple project files
-the  #pragma comment code below looks like it gets too spaghetti-ish too
quickly

Cheers,
Dan

>
> On Jan 16, 2008, at 2:19 PM, [EMAIL PROTECTED] wrote:
>
>> You can solve this by creating additional configurations in the same
>> VS
>> projects/solution.  Configurations are set up to let you choose
>> different
>> link libraries for different targets.  The different targets can
>> also set
>> different #defines to select CG vs Cairo, etc.
>>
>> Personally I don't like this so much since it is a pain to maintain
>> multiple configurations, but it does solve the problem for selecting
>> different libraries to link.
>>
>> Cheers,
>> Dan
>>
>>> This was a non-issue for Cairo, since it was completely contained in
>>> our source tree (and not externally linked against).  That was less
>>> than ideal though, and you still had the linking problem in the other
>>> direction (with CG always being linked against).
>>>
>>> dave
>
> You can link against different libraries using the Visual Studio
> "#pragma comment" feature, e.g.:
>
> #pragma comment(lib, "wininet.lib")
>
> This works, but if you want to link against debug and other variants,
> you quickly end up with a mess like:
>
> #ifdef _DEBUG
> #ifdef _UNICODE_
> #pragma comment (lib, "coollibDU.lib")
> #else
> #pragma comment (lib, "coollibD.lib")
> #endif
> #else
> #ifdef _UNICODE_
> #pragma comment (lib, "coollibU.lib")
> #else
> #pragma comment (lib, "coollib.lib")
> #endif
> #endif
>
> I think for us to have a viable native windows port, we need to be
> able to link against a pre-built Cairo libraries.
>
> I am just not looking forward to having to create multiple targets in
> the project files, as this will involve figuring out how to pass this
> along from the "build-webkit" script, etc., etc.
>
> But can we decide on a course of action soon?  I'd like to generate a
> patch that gets the win32 (native) target to build soon, but I don't
> want to spend too much time on a dead-end.
>
> Thanks,
> -Brent
>


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Pulling together on WebKit Mobile

[zucker]

You can solve this by creating additional configurations in the same VS
projects/solution.  Configurations are set up to let you choose different
link libraries for different targets.  The different targets can also set
different #defines to select CG vs Cairo, etc.

Personally I don't like this so much since it is a pain to maintain
multiple configurations, but it does solve the problem for selecting
different libraries to link.

Cheers,
Dan

> This was a non-issue for Cairo, since it was completely contained in
> our source tree (and not externally linked against).  That was less
> than ideal though, and you still had the linking problem in the other
> direction (with CG always being linked against).
>
> dave
>
> On Jan 16, 2008, at 4:10 PM, Adam Roben wrote:
>
>> On Jan 16, 2008, at 5:04 PM, David Hyatt wrote:
>>
>>> This is how we did it when we (briefly) had CG and Cairo compiling
>>> simultaneously.  The problem with it though is that we had a copy
>>> of Cairo in our source tree and ended up having to hack the Cairo
>>> source to put #if PLATFORM(CAIRO) around those files.  If Cairo is
>>> going to be brought in externally, that could be an issue.
>>
>> And in general, #ifdefing the contents of source files doesn't solve
>> the problem of choosing which libs to link against.
>>
>> -Adam
>>
>>> On Jan 16, 2008, at 3:58 PM, [EMAIL PROTECTED] wrote:
>>>
 I like the idea of just wrapping those files with #if PLATFORM(CG).

 It's slightly messy, but it works and it simplifies managing a
 complex VS
 project file.

 Cheers,
 Dan

  Original Message
 
 Subject: Fwd: [webkit-dev] Pulling together on WebKit Mobile
 Date:Wed, January 16, 2008 1:54 pm
 --

 On 16/01/2008, at 1:28 PM, Brent Fulgham wrote:

> I took Dan's advice, and modified my config.h as follows:
>
> #if PLATFORM(WIN)
> #define WTF_USE_JAVASCRIPTCORE_BINDINGS 1
> #define WTF_USE_NPOBJECT 1
> #undef WTF_PLATFORM_CG
> #define WTF_PLATFORM_CAIRO 1
> #undef WTF_USE_CFNETWORK
> #define WTF_USE_WININET 1
> #undef WTF_PLATFORM_CF
> #define WTF_USE_PTHREADS 0
> #endif
>
> We should probably come up with a new name for a 'native'
> windows build, such as used by Adobe/AIR, Windows mobile, and a
> true native Windows build.
>
> I also modified Visual Studio's environment to find the Cairo
> headers and link libraries.
>
> I then started "build-webkit" and went and did other things for
> about an hour.  The build produces quite a few errors, many of
> which are just CG-isms that I conditionalized away.  In a few
> cases, I resurrected the old Cairo backend code, in others I just
> marked them as 'notImplemented()'.
>
> At this point, the remaining errors are due to the Visual Studio
> project compiling the CG modules.  I'm not sure how best to
> approach this:
>
> 1.  Create a brand new project for non-CG Windows
> 2.  Create new build targets in the existing solution for the non-
> CG target.
> 3.  ?

 Possibly worth putting #if PLATFORM(CG) around SG paltform files,
 but
 i also can't think of a nice way to work around this -- does anyone
 know if you can make VS recognise some files as being for one target
 only?

 --Oliver

>
>
> -Brent
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev
>>>
>>> ___
>>> webkit-dev mailing list
>>> webkit-dev@lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>
>


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Pulling together on WebKit Mobile

[zucker]

I like the idea of just wrapping those files with #if PLATFORM(CG).

It's slightly messy, but it works and it simplifies managing a complex VS
project file.

Cheers,
Dan

 Original Message 
Subject: Fwd: [webkit-dev] Pulling together on WebKit Mobile
Date:Wed, January 16, 2008 1:54 pm
--

On 16/01/2008, at 1:28 PM, Brent Fulgham wrote:

> I took Dan's advice, and modified my config.h as follows:
>
> #if PLATFORM(WIN)
> #define WTF_USE_JAVASCRIPTCORE_BINDINGS 1
> #define WTF_USE_NPOBJECT 1
> #undef WTF_PLATFORM_CG
> #define WTF_PLATFORM_CAIRO 1
> #undef WTF_USE_CFNETWORK
> #define WTF_USE_WININET 1
> #undef WTF_PLATFORM_CF
> #define WTF_USE_PTHREADS 0
> #endif
>
> We should probably come up with a new name for a 'native'
> windows build, such as used by Adobe/AIR, Windows mobile, and a
> true native Windows build.
>
> I also modified Visual Studio's environment to find the Cairo
> headers and link libraries.
>
> I then started "build-webkit" and went and did other things for
> about an hour.  The build produces quite a few errors, many of
> which are just CG-isms that I conditionalized away.  In a few
> cases, I resurrected the old Cairo backend code, in others I just
> marked them as 'notImplemented()'.
>
> At this point, the remaining errors are due to the Visual Studio
> project compiling the CG modules.  I'm not sure how best to
> approach this:
>
> 1.  Create a brand new project for non-CG Windows
> 2.  Create new build targets in the existing solution for the non-
> CG target.
> 3.  ?

Possibly worth putting #if PLATFORM(CG) around SG paltform files, but
i also can't think of a nice way to work around this -- does anyone
know if you can make VS recognise some files as being for one target
only?

--Oliver

>
>
> -Brent
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
-- Forwarded message --From: Oliver Hunt <[EMAIL PROTECTED]>Date: Jan 16, 2008 1:37 PM
Subject: Re: [webkit-dev] Pulling together on WebKit MobileTo: Brent Fulgham <[EMAIL PROTECTED]>Cc: webkit-dev@lists.webkit.org
On 16/01/2008, at 1:28 PM, Brent Fulgham wrote:> I took Dan's advice, and modified my config.h as follows:>> #if PLATFORM(WIN)> #define WTF_USE_JAVASCRIPTCORE_BINDINGS 1
> #define WTF_USE_NPOBJECT 1> #undef WTF_PLATFORM_CG> #define WTF_PLATFORM_CAIRO 1> #undef WTF_USE_CFNETWORK> #define WTF_USE_WININET 1> #undef WTF_PLATFORM_CF> #define WTF_USE_PTHREADS 0
> #endif>> We should probably come up with a new name for a 'native'> windows build, such as used by Adobe/AIR, Windows mobile, and a> true native Windows build.
>> I also modified Visual Studio's environment to find the Cairo> headers and link libraries.>> I then started "build-webkit" and went and did other things for> about an hour.  The build produces quite a few errors, many of
> which are just CG-isms that I conditionalized away.  In a few> cases, I resurrected the old Cairo backend code, in others I just> marked them as 'notImplemented()'.>> At this point, the remaining errors are due to the Visual Studio
> project compiling the CG modules.  I'm not sure how best to> approach this:>> 1.  Create a brand new project for non-CG Windows> 2.  Create new build targets in the existing solution for the non-
> CG target.> 3.  ?Possibly worth putting #if PLATFORM(CG) around SG paltform files, buti also can't think of a nice way to work around this -- does anyoneknow if you can make VS recognise some files as being for one target
only?--Oliver>>> -Brent> ___> webkit-dev mailing list> 
webkit-dev@lists.webkit.org> http://lists.webkit.org/mailman/listinfo/webkit-dev___
webkit-dev mailing listwebkit-dev@lists.webkit.orghttp://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Pulling together on WebKit Mobile

[zucker]

> This isn't too surprising -- code that isn't used quickly goes stale.
> But it should be quite possible to fix!
>

Thus, my suggestion to do this work :).

Cheers,
Dan

> [EMAIL PROTECTED] wrote:
>>> What sort of errors? link errors?
>>>
>>
>> As a quick test, I #undef'ed WTF_PLATFORM_CG, WTF_USE_CFNETWORK, and
>> WTF_PLATFORM_CF; and instead #define'd WTF_PLATFORM_CAIRO and
>> WTF_USE_WININET.
>>
>> Building WebCore alone resulted in 389 compile errors.
>>
>> The basic structure of using these #defines seems good.  But apparently,
>> when CF, CG, and CFNetwork were added, the previous constructs were
>> badly
>> broken.
>>
>
> This isn't too surprising -- code that isn't used quickly goes stale.
> But it should be quite possible to fix!
>
> -Adam
>
>>
>>> On 14/01/2008, at 4:26 PM, [EMAIL PROTECTED] wrote:
>>>
>>>
> The windows code the depends on apple libraries are either in CG/CF
> specific files,
> or PLATFORM(CG)/PLATFORM(CF).  The expectation would be that you'd be
> adding
> PLATFORM(WINCE) or PLATFORM(GDI) or some such.
>
>
 Agreed.  My point is that if you try to compile now using WININET,
 CAIRO,
 etc. instead of CG, CF, CN, you get _lots_ of errors.

>>> What sort of errors? link errors? PLATFORM(QT) can compile on
>>> windows, so
>>> if PLATFORM(WININET) PLATFORM(CAIRO) fails it implies there is either
>>> some
>>> code making incorrect assumptions about the PLATFORM, missing file
>>> guards,
>>> or more likely, unimplemented PLATFORM functionality.
>>>
>>>
> The best and easiest way to discuss this would be on IRC in the
> #webkit channel of
> freenode...
>
 Sure, but it seems tough to get a time when everyone interested is on.
 Should we set a time to discuss this?

>>> I think you'd be safe anywhere between 2pm and 10pm PST, although
>>> that's
>>> only an educated guess based on my recollection of when GTK, QT, and
>>> Apple
>>> folk are around.
>>>
>>> --Oliver
>>>
>>>
 Cheers,
 Dan


> On 14/01/2008, at 3:48 PM, [EMAIL PROTECTED] wrote:
>
>> My main concern is to make sure Windows Mobile code is part of the
>> main
>> trunk, and not a side branch.  My recommended first step to make
>> the trunk
>> more Windows Mobile friendly is to update the Windows version to
>> build
>> without requiring proprietary Apple libraries.
>>
>> How does the community feel about this?
>>
> The windows code the depends on apple libraries are either in CG/CF
> specific files,
> or PLATFORM(CG)/PLATFORM(CF).  The expectation would be that you'd be
> adding
> PLATFORM(WINCE) or PLATFORM(GDI) or some such.
>
> The best and easiest way to discuss this would be on IRC in the
> #webkit channel of
> freenode...
>
> --Oliver
>
>
>

>>>
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Pulling together on WebKit Mobile

[zucker]

> What sort of errors? link errors?

As a quick test, I #undef'ed WTF_PLATFORM_CG, WTF_USE_CFNETWORK, and
WTF_PLATFORM_CF; and instead #define'd WTF_PLATFORM_CAIRO and
WTF_USE_WININET.

Building WebCore alone resulted in 389 compile errors.

The basic structure of using these #defines seems good.  But apparently,
when CF, CG, and CFNetwork were added, the previous constructs were badly
broken.

Cheers,
Dan

> On 14/01/2008, at 4:26 PM, [EMAIL PROTECTED] wrote:
>
>>> The windows code the depends on apple libraries are either in CG/CF
>>> specific files,
>>> or PLATFORM(CG)/PLATFORM(CF).  The expectation would be that you'd be
>>> adding
>>> PLATFORM(WINCE) or PLATFORM(GDI) or some such.
>>>
>>
>> Agreed.  My point is that if you try to compile now using WININET,
>> CAIRO,
>> etc. instead of CG, CF, CN, you get _lots_ of errors.
>
> What sort of errors? link errors? PLATFORM(QT) can compile on
> windows, so
> if PLATFORM(WININET) PLATFORM(CAIRO) fails it implies there is either
> some
> code making incorrect assumptions about the PLATFORM, missing file
> guards,
> or more likely, unimplemented PLATFORM functionality.
>
>>
>>> The best and easiest way to discuss this would be on IRC in the
>>> #webkit channel of
>>> freenode...
>>
>> Sure, but it seems tough to get a time when everyone interested is on.
>> Should we set a time to discuss this?
>
> I think you'd be safe anywhere between 2pm and 10pm PST, although that's
> only an educated guess based on my recollection of when GTK, QT, and
> Apple
> folk are around.
>
> --Oliver
>
>>
>> Cheers,
>> Dan
>>
>>>
>>> On 14/01/2008, at 3:48 PM, [EMAIL PROTECTED] wrote:
 My main concern is to make sure Windows Mobile code is part of the
 main
 trunk, and not a side branch.  My recommended first step to make
 the trunk
 more Windows Mobile friendly is to update the Windows version to
 build
 without requiring proprietary Apple libraries.

 How does the community feel about this?
>>>
>>> The windows code the depends on apple libraries are either in CG/CF
>>> specific files,
>>> or PLATFORM(CG)/PLATFORM(CF).  The expectation would be that you'd be
>>> adding
>>> PLATFORM(WINCE) or PLATFORM(GDI) or some such.
>>>
>>> The best and easiest way to discuss this would be on IRC in the
>>> #webkit channel of
>>> freenode...
>>>
>>> --Oliver
>>>
>>>
>>
>>
>
>


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Pulling together on WebKit Mobile

[zucker]

> The windows code the depends on apple libraries are either in CG/CF
> specific files,
> or PLATFORM(CG)/PLATFORM(CF).  The expectation would be that you'd be
> adding
> PLATFORM(WINCE) or PLATFORM(GDI) or some such.
>

Agreed.  My point is that if you try to compile now using WININET, CAIRO,
etc. instead of CG, CF, CN, you get _lots_ of errors.

> The best and easiest way to discuss this would be on IRC in the
> #webkit channel of
> freenode...

Sure, but it seems tough to get a time when everyone interested is on. 
Should we set a time to discuss this?

Cheers,
Dan

>
> On 14/01/2008, at 3:48 PM, [EMAIL PROTECTED] wrote:
>> My main concern is to make sure Windows Mobile code is part of the
>> main
>> trunk, and not a side branch.  My recommended first step to make
>> the trunk
>> more Windows Mobile friendly is to update the Windows version to build
>> without requiring proprietary Apple libraries.
>>
>> How does the community feel about this?
>
> The windows code the depends on apple libraries are either in CG/CF
> specific files,
> or PLATFORM(CG)/PLATFORM(CF).  The expectation would be that you'd be
> adding
> PLATFORM(WINCE) or PLATFORM(GDI) or some such.
>
> The best and easiest way to discuss this would be on IRC in the
> #webkit channel of
> freenode...
>
> --Oliver
>
>


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Pulling together on WebKit Mobile

[zucker]

Dear WebKit Team,

Going back to the original topic (Pulling together on WebKit Mobile)

Wake3 has a working version of WebKit for Windows Mobile.  We definitely
want to contribute back to the community.  We posted earlier about this,
but didn't get much of a reply.

For more information on Wake3, see the video demo on our website at
www.wake3.com.  We also gave a live demo at a recent Silicon Valley Mobile
Monday event (see our presentation at http://www.mobilemonday.us/?p=188). 
We are planning a public Beta in the next few months and we plan to
release source then.

My main concern is to make sure Windows Mobile code is part of the main
trunk, and not a side branch.  My recommended first step to make the trunk
more Windows Mobile friendly is to update the Windows version to build
without requiring proprietary Apple libraries.

How does the community feel about this?

Last, we will be at the Mobile World Congress (formerly 3GSM Congress)
next month in Barcelona.  Send email if you want to meet up and see a
demo.

Cheers,
Dan

Daniel F. Zucker, PhD
CTO, Wake3

---
We had ported S60Wekbit to WinCE.
What S60Webkit or Webkit subversion repositories to merge them?


Sincerely
wormwang

-邮件原件-
发件人: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 代表 Alp Toker
发送时间: 2008年1月12日 2:38
收件人: Peter Schojer
抄送: Naiem Shaik; webkit-dev@lists.webkit.org
主题: [webkit-dev] Pulling together on WebKit Mobile
- Hide quoted text -

Hey guys,

There's a lot of mobile WebKit expertise in different organisations and
from various individuals, but we haven't really done much to put it all
in one place so far.

Would you be interested in sharing your findings, internal documentation
and patches?

Some things I'd like to see:

 * Build fixes for various lightweight toolchains integrated into TOT

 * Documentation of optional defines used in the WebCore loader and
elsewhere, like LOW_BANDWIDTH_DISPLAY and MOBILE

 * Build instructions made public (Scratchbox, cross-compilation etc.)

 * Compiler flags

 * Bug workarounds for different architectures and toolchains

I'd love to see what Naiem's team is finding and fixing in the GTK+
port, what tweaks the iPhone and Android engineers are using, and the
lightweight libc fixes from Peter, and Collabora's findings on the Nokia
internet tablets all in one place.

When patches get merged, the WebKit team will help you maintain them so
contributing code can help reduce the burden of maintaining ports and
build fixes out-of-tree.

I have some material I've built up privately in the last year on ARM
including benchmarks and patches that I'd like to start sharing too.

I do think we can get more done if we work together here. I've set up a
wiki page -- please edit this with your findings and suggestions:

  http://trac.webkit.org/projects/webkit/wiki/Mobile

You can register an account on the wiki here:

  http://trac.macosforge.org/projects/webkit/register
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] We are porting webkit to windows ce

[zucker]

Dear WebKit Team,

As you can see from our video demo (at www.wake3.com), we already have a
functional WebKit WinCE port.

We definitely are ready, willing, and able to be part of a WebKit WinCE
project.

For us, an important goal is to make sure the WinCE version takes
advantage of all the bug fixes continually coming into the main WebKit
trees.  For this reason, we advocate integrating the WinCE version into
the main tree rather than starting a spinoff project.

What are the thoughts from the community?

Cheers,
Dan

CTO, Wake3

>On 30-Oct-07, at 2:22 AM, Maciej Stachowiak wrote:
>
>>>  Below is a document I have written up describing the webkit port
>>> that our team want to build. We’d like to know what the community
>>> thinks of
>>> the port we are proposing.
>>
>> Sounds like a neat idea. Keep in mind that Safari is a registered
>> trademark of Apple Inc. So I suggest picking a different name for
>> the project.
>>
>> Also, a company called Wake3 apparently already has a Windows CE
>> port in progress: . They have not released
>> any code yet as far as I know, but you may wish to get in touch
>> with them.
>
>  We also have WebKit up and running on WinCE.
>
>--
>George Staikos
>KDE Developer   http://www.kde.org/
>Staikos Computing Services Inc. http://www.staikos.net/


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev