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
buil
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 #defi
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
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,
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 tho
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 ex
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
>
> > 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.
>
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
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
Le mardi 15 janvier 2008 à 01:19 -0800, Maciej Stachowiak a écrit :
> On Jan 14, 2008, at 8:02 PM, Adam Roben wrote:
>
> > Oliver Hunt wrote:
> >> On 14/01/2008, at 4:26 PM, [EMAIL PROTECTED] wrote:
> >>
> The best and easiest way to discuss this would be on IRC in the
> #webkit channel
On Jan 14, 2008, at 8:02 PM, Adam Roben wrote:
Oliver Hunt wrote:
On 14/01/2008, at 4:26 PM, [EMAIL PROTECTED] wrote:
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.
Sho
> 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
[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 usi
> 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.
On Jan 14, 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 p
Oliver Hunt wrote:
On 14/01/2008, at 4:26 PM, [EMAIL PROTECTED] wrote:
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
On Jan 14, 2008, at 3:48 PM, [EMAIL PROTECTED] wrote:
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
t
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
> 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.
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 prop
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 Wak
Hi,
Le 12 janv. 08 à 08:51, Mark Rowe a écrit :
Another immediate need is if you did this I'd like to ask Pleyo to
move there development over
to this new open git server. Pleyo has done some fairly innovative
work but they have diverged
from the main tree and it would take time and effort to
Then make it SVN I don't care.
If git is that big of a hurdle then create a collaboration are using SVN.
I did not mean to get into a git vs svn match. Git just seemed to me to
be a better choice for the type of branching and merging and needed for a
collaboration area.
SVN, cvs rcs, sccs anyth
On 12/01/2008, at 18:13, Mike Emmel wrote:
Webkit is a fairly sophisticated piece of code using git for daily
development is
trivial. I'd expect any developer who was collaborating on webkit
would also be
capable of learning git.
Something as simple as this is sufficient.
http://zrusin.blo
On Jan 11, 2008 1:26 PM, Mark Rowe <[EMAIL PROTECTED]> wrote:
>
> On 12/01/2008, at 07:55, Mike Emmel wrote:
>
> > I'd like for it to be very easy to contribute a git tree with commit
> > rights that was acceptable to the WebKit community
> > would make it very easy to create branches for bug fixes
On 12/01/2008, at 07:55, Mike Emmel wrote:
I'd like for it to be very easy to contribute a git tree with commit
rights that was acceptable to the WebKit community
would make it very easy to create branches for bug fixes and and as a
work area.
And it makes it easy to allow outstanding patches t
On Jan 11, 2008 12:14 PM, Mark Rowe <[EMAIL PROTECTED]> wrote:
> [This is drifting far from Alp's original email. I hope the points he
> raised are not overlooked due to discussion on this very tangential
> topic.]
>
>
> On 12/01/2008, at 06:55, Mike Emmel wrote:
>
> > And its a good way to allow
I have no problems with the commit requirements for the main tree.
This is more about a collaboration area.
It make more sense for WebKit.org to host a collaboration area.
And its a good way to allow developers to build up a work history to
ask for main commit rights.
Its a public work area and
[This is drifting far from Alp's original email. I hope the points he
raised are not overlooked due to discussion on this very tangential
topic.]
On 12/01/2008, at 06:55, Mike Emmel wrote:
And its a good way to allow developers to build up a work history to
ask for main commit rights.
On Jan 11, 2008 11:29 AM, Oliver Hunt <[EMAIL PROTECTED]> wrote:
>
> On 11/01/2008, at 10:54 AM, Mike Emmel wrote:
> > I think this approach will allow us to keep the main repository and
> > tree clean and foster the churn that makes open source development fun
> > and exciting.
> >
> > Contributin
On 11/01/2008, at 10:54 AM, Mike Emmel wrote:
I think this approach will allow us to keep the main repository and
tree clean and foster the churn that makes open source development fun
and exciting.
Contributing to webkit is not a fun and exciting process at the
moment.
There's already a gi
I think one of the biggest stumbling blocks is the lack of a shared
workspace for development.
The patch approach is good for bugs but falls apart when multiple
people from different organizations are working on new code.
However I like the review process in place before code is included in
the m
33 matches
Mail list logo
