[webkit-dev] Re: Moving away from qmake

2007-11-16 Thread Alp Toker

Steve Atkins wrote:

IIRC, the two issues were that qmake is time-consuming to build and
that the existing .pro files were not handling dependencies correctly.

Is the latter the only issue now, or were there other problems?


This probably reduces the urgency for change. I think we need to wait a 
week or two to see if new developers have more success with the updated 
build instructions on the wiki.


I've seen some commits on the Trolltech git tree starting to clean up 
the qmake build files. If the dependency tracking issues are solved, 
someone explains/removes the redundant duplication in the build files, 
and if new developers start having better luck with the standalone 
qmake4 package, it might be an option to stick with qmake for longer.


If we get that far, it would be easy to achieve a near-ideal build 
system for the GTK+ port using autoconf for configuration and qmake for 
the rest of the job and avoiding automake, so we don't have to duplicate 
the lists of sources but still get a flexible and well-understood 
configuration system. git itself is one example of a software project 
that uses autoconf but not automake.

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


Re: [webkit-dev] Re: Moving away from qmake

2007-11-16 Thread Steve Atkins


On Nov 16, 2007, at 12:58 PM, Alp Toker wrote:


Alp Toker wrote:
you have to build the whole of Qt just to get qmake, which takes  
over an
hour and almost a gigabyte of disk space for me. That's at least 5  
times

as long as it takes to build the whole of JavaScriptCore, WebCore and
WebKit.


Just to set the record straight, it turned out my bad experience  
building Qt was with a debug build of a pre-release version from  
some months ago. I hear building the whole thing is not so  
difficult, and there is even a standalone qmake tarball available now.


My bad on that point. I think the rest of the discourse is still  
valid.


IIRC, the two issues were that qmake is time-consuming to build and
that the existing .pro files were not handling dependencies correctly.

Is the latter the only issue now, or were there other problems?

Cheers,
  Steve

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


[webkit-dev] Re: Moving away from qmake

2007-11-16 Thread Alp Toker

Alp Toker wrote:

you have to build the whole of Qt just to get qmake, which takes over an
hour and almost a gigabyte of disk space for me. That's at least 5 times
as long as it takes to build the whole of JavaScriptCore, WebCore and
WebKit.


Just to set the record straight, it turned out my bad experience 
building Qt was with a debug build of a pre-release version from some 
months ago. I hear building the whole thing is not so difficult, and 
there is even a standalone qmake tarball available now.


My bad on that point. I think the rest of the discourse is still valid.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Re: Moving away from qmake (aka. modularising JavaScriptCore)

2007-11-12 Thread Alp Toker

Mike Emmel wrote:

I refactored all the Unicode handling to run behind a abstract interface.
So no direct ICU calls.

Its a lot of little patches all over the place and a thankless job.
Its a lot of work so email me if your interested.

I was also looking at repacling icu with glib/pango.

Its not clear you get everything you need from glib so I believe you
have to bring in pango
which does more than you want.  Pango itself needs to be split into text metrics
and glyph drawing.



It's also worth mentioning the new HarfBuzz library:

http://www.freedesktop.org/wiki/Software/HarfBuzz

It's pretty simple to follow the API if you check out the git 
repository. It's done in the style of FreeType which is kind of cute.


HarfBuzz can certainly be used to do some of the text handling in WebCore.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Re: Moving away from qmake

2007-11-12 Thread Mike Emmel
Yes I rewrote the Curl code to use the new callback api's so you can
use select in the main thread.

Also the Pleyo people have done some work I've not fully integrated so
their work is worth looking at.

I ran into some issues and dropped back for the time being to a full
load on each call. Its a nice debugging feature anyway.

Also the latest curl uses asynchronous DNS resolution a huge win.

The biggest problem with Curl right now is that completion messages
still have to be polled for I was going to talk with the curl guys and
patch so you can register a callback.

Attached is my current curl the new stuff is turned off and I'm just loading.

Also this has some nice code in it esp for gtk that binds curl to the
gtk event loop.

http://www.gnomefiles.org/app.php/gCurl

If you read the code and think about the problem that the completion
messages get put on a queue inside curl
and you have to poll for them then you will see why I really want to
fix this in curl.

Also I seemed to be crashing inside curl sometimes with this turned on.


On Nov 12, 2007 12:11 AM, Alp Toker <[EMAIL PROTECTED]> wrote:
> Mike Emmel wrote:
> > Here is my autoconf build files
> >
> > They are for my current  projects but I think they could readily be
> > cleaned up to b used with the standard build.
> > I found that having a single Makefile did not incur any performance 
> > problems.
>
> Mike, just had a look over this and it's looking like a good start. Thanks!
>
> Was wondering, do you have any fixes to the Cairo graphics or CURL http
> backends in your tree, or anything that might be useful to WebKit upstream?
>
> If you provide your HTTP fixes, for example, I'll have more time to fix
> the remaining Cairo SVG bugs, which you can then pull back into your
> private branch, so everyone wins.
>
/*
 * Copyright (C) 2004, 2006 Apple Computer, Inc.  All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY APPLE COMPUTER, INC. ``AS IS'' AND ANY
 * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL APPLE COMPUTER, INC. OR
 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
 * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
 * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
 * OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 
 */

#ifndef ResourceHandle_h
#define ResourceHandle_h

#include "AuthenticationChallenge.h"
#include "HTTPHeaderMap.h"
#include 


#if PLATFORM(WIN)
typedef unsigned long DWORD;
typedef unsigned long DWORD_PTR;
typedef void* LPVOID;
typedef LPVOID HINTERNET;
typedef unsigned WPARAM;
typedef long LPARAM;
typedef struct HWND__* HWND;
typedef _W64 long LONG_PTR;
typedef LONG_PTR LRESULT;
#endif


#if PLATFORM(MAC)
#include 
#ifdef __OBJC__
@class NSData;
@class NSError;
@class NSURLConnection;
@class WebCoreResourceHandleAsDelegate;
#else
class NSData;
class NSError;
class NSURLConnection;
class WebCoreResourceHandleAsDelegate;
typedef struct objc_object *id;
#endif
#endif

#if USE(CFNETWORK)
typedef struct _CFURLConnection* CFURLConnectionRef;
typedef int CFHTTPCookieStorageAcceptPolicy;
typedef struct OpaqueCFHTTPCookieStorage* CFHTTPCookieStorageRef;
#endif

#if USE(CURL)
typedef struct CURLMsg CURLMsg;
#endif

namespace WebCore {

class AuthenticationChallenge;
class Credential;
class FormData;
class Frame;
class KURL;
class ResourceError;
class ResourceHandleClient;
class ResourceHandleInternal;
class ResourceRequest;
class ResourceResponse;
class SharedBuffer;
class SubresourceLoader;
class SubresourceLoaderClient;

template  class Timer;

class ResourceHandle : public Shared {
private:
ResourceHandle(const ResourceRequest&, ResourceHandleClient*, bool defersLoading, bool mightDownloadFromHandle);

public:
// FIXME: should not need the Frame
static PassRefPtr create(const ResourceRequest&, ResourceHandleClient*, Frame*, bool defersLoading, bool mightDownloadFromHandle = false);

static void loadResourceSynchronously(const ResourceRequest&, ResourceError&, ResourceResponse&, Vector& data);
static bool willLoadFromCache(ResourceRequest&);

~ResourceHandle();

#if PLATF

[webkit-dev] Re: Moving away from qmake

2007-11-12 Thread Alp Toker

Mike Emmel wrote:

Here is my autoconf build files

They are for my current  projects but I think they could readily be
cleaned up to b used with the standard build.
I found that having a single Makefile did not incur any performance problems.


Mike, just had a look over this and it's looking like a good start. Thanks!

Was wondering, do you have any fixes to the Cairo graphics or CURL http 
backends in your tree, or anything that might be useful to WebKit upstream?


If you provide your HTTP fixes, for example, I'll have more time to fix 
the remaining Cairo SVG bugs, which you can then pull back into your 
private branch, so everyone wins.

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