On May 24, 2009, at 10:38 PM, Adam Barth wrote:
On Sun, May 24, 2009 at 10:08 PM, Maciej Stachowiak m...@apple.com
wrote:
I don't think it should be discounted. It might be helpful to
clarify why
you think ifdefs are a bad solution.
When I made changes that affect several ports, I try to
On May 24, 2009, at 10:51 PM, Peter Kasting wrote:
On Sun, May 24, 2009 at 10:08 PM, Maciej Stachowiak m...@apple.com
wrote:
I don't think it should be discounted. It might be helpful to
clarify why you think ifdefs are a bad solution.
Generally they make it more difficult to read the
Hi Maciej,
On May 25, 2009, at 12:33 AM, Maciej Stachowiak wrote:
On May 24, 2009, at 10:38 PM, Adam Barth wrote:
On Sun, May 24, 2009 at 10:08 PM, Maciej Stachowiak m...@apple.com
wrote:
I don't think it should be discounted. It might be helpful to
clarify why
you think ifdefs are a
On Mon, May 25, 2009 at 12:49 AM, Maciej Stachowiak m...@apple.com wrote:
Now, the thing I _would_ like to change is to switch from pathless
#includes to ones with relative paths -- but that's a totally different
thread.
That I definitely wouldn't like. It would make it much more painful to
On 2009-05-25, at 13:19, Peter Kasting wrote:
On Mon, May 25, 2009 at 12:49 AM, Maciej Stachowiak m...@apple.com
wrote:
Now, the thing I _would_ like to change is to switch from pathless
#includes to ones with relative paths -- but that's a totally
different thread.
That I definitely
On May 23, 2009, at 9:38 AM, David Kilzer wrote:
Another aspect of this proposal is how to handle source files that
have #if ENABLE(FEATURE)/#endif guards around all of their source
code, for example:
Bug 25756: Explicit guards for ENABLE_GEOLOCATION
nbsp;Well , It seems we're on thenbsp;similar problem. I posted a question in
lib change questions, for I found migrating webkit on other platformnbsp; or
replacing some libs is very time-costing.
nbsp;
So, if all the work can be fixed through building, it must be a big
On Sun, May 24, 2009 at 12:19 AM, Maciej Stachowiak m...@apple.com wrote:
On May 23, 2009, at 9:38 AM, David Kilzer wrote:
There are essentially two options here:
1. Add #if/#endif guards to entire source files, but include every file in
every build system.
2. Make each build system smart
On May 24, 2009, at 9:28 PM, Peter Kasting wrote:
On Sun, May 24, 2009 at 12:19 AM, Maciej Stachowiak m...@apple.com
wrote:
On May 23, 2009, at 9:38 AM, David Kilzer wrote:
There are essentially two options here:
1. Add #if/#endif guards to entire source files, but include every
file in
On Sun, May 24, 2009 at 10:08 PM, Maciej Stachowiak m...@apple.com wrote:
I don't think it should be discounted. It might be helpful to clarify why
you think ifdefs are a bad solution.
When I made changes that affect several ports, I try to be good WebKit
citizen and update all the ports, but
Another aspect of this proposal is how to handle source files that have #if
ENABLE(FEATURE)/#endif guards around all of their source code, for example:
Bug 25756: Explicit guards for ENABLE_GEOLOCATION
https://bugs.webkit.org/show_bug.cgi?id=25756
There are essentially two options here:
1. Add
: Maciej Stachowiak m...@apple.com
Subject: Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
To: mbe...@pleyo.com
Cc: webkit-dev@lists.webkit.org
Date: Tuesday, May 5, 2009, 11:19 PM
On May 4, 2009, at 5:21 AM, Mario Bensi wrote:
We pursued the same goal for a couple of years
The goal of Origyn Web Browser Abstraction Layer (OWBAL) is to clarify what is
platform dependant and what is not.
In BAL directory you find some modules which split sources per family of
feature:
Database: all files needed for HTML5 Database and Storage.
Events: all events definitions
On 5-May-09, at 10:49 AM, Darin Adler wrote:
On May 4, 2009, at 7:45 PM, George Staikos wrote:
1) In some cases some things apply to more than one OS so we have:
#if OS(x) || OS(y) || OS(z) ...
I think we should use:
#if OS(x,y,z)
How? Macros don’t have overloading with the same macro but
will be to clean that up.
Dave
From: George Staikos stai...@kde.org
To: WebKit Development webkit-dev@lists.webkit.org
Sent: Monday, May 4, 2009 7:45:41 PM
Subject: Re: [webkit-dev] Proposal for a new way to handle porting #ifdefs
I really like this and it goes
On May 4, 2009, at 7:45 PM, George Staikos wrote:
1) In some cases some things apply to more than one OS so we have:
#if OS(x) || OS(y) || OS(z) ...
I think we should use:
#if OS(x,y,z)
How? Macros don’t have overloading with the same macro but different
numbers of parameters.
3) I'm not
On May 4, 2009, at 7:45 PM, George Staikos wrote:
I really like this and it goes in the direction that I was hoping
for as well. Hopefully we can get the WINCE port merged upstream
before we make this change. :-)
Some comments I have:
1) In some cases some things apply to more than
On May 4, 2009, at 5:21 AM, Mario Bensi wrote:
We pursued the same goal for a couple of years. Since our porting
targets are various middleware CE platforms, we had to identify and
adapt WebKit needs at a better grained level than platform.
In order to do this we collected all dependencies in
We pursued the same goal for a couple of years. Since our porting
targets are various middleware CE platforms, we had to identify and
adapt WebKit needs at a better grained level than platform.
In order to do this we collected all dependencies in a Browser
Abstraction Layer (BAL directory).
I really like this and it goes in the direction that I was hoping for
as well. Hopefully we can get the WINCE port merged upstream before
we make this change. :-)
Some comments I have:
1) In some cases some things apply to more than one OS so we have:
#if OS(x) || OS(y) || OS(z) ...
I
This looks great to me. It will definitely make ports more maintainable.
For thoroughness sake, it would be good to add a bit about what should be a
USE define versus a setting. For example, the EditingBehavior enum in
Settings.h could just as easily be a USE define. I think it makes sense in
this
Maciej,
This sounds good, and sounds like it could clean things up a lot.
In the breakdown below you don't explicitly mention what would happen
to h/w specific macros like PLATFORM_X86, though you do mention 'CPU'
in your email, OOI are you thinking something like?:
CPU()
Examples:
On Apr 30, 2009, at 4:50 PM, Ojan Vafai wrote:
This looks great to me. It will definitely make ports more
maintainable.
For thoroughness sake, it would be good to add a bit about what
should be a USE define versus a setting. For example, the
EditingBehavior enum in Settings.h could just
On Apr 30, 2009, at 5:02 PM, Gavin Barraclough wrote:
Maciej,
This sounds good, and sounds like it could clean things up a lot.
In the breakdown below you don't explicitly mention what would
happen to h/w specific macros like PLATFORM_X86, though you do
mention 'CPU' in your email, OOI
24 matches
Mail list logo
