Re: [webkit-dev] [Styling] () for a lambda without arguments (Was Space between [] and () in C++ lambdas)

[Zalan Bujtas]

I've been using the short form in the layout code for a while now and never
mistaken it for code block start & end.
That being said I don't have strong preference on this.

Alan.

On Fri, Nov 1, 2019 at 4:37 PM Ryosuke Niwa  wrote:

> On Fri, Nov 1, 2019 at 11:53 AM Michael Catanzaro 
> wrote:
>
>> On Fri, Nov 1, 2019 at 11:19 am, Ryosuke Niwa  wrote:
>> > Namely, some people write a lambda as:
>> > auto x = [] () { }
>> >
>> > with a space between [] and () while others would write it as:
>> >
>> > auto x = []() { }
>>
>> : I omit the () when there are no parameters, as in these examples.
>>
>
> I guess that's another thing we should decide. Should we, or should we not
> have () when there are no arguments.
>
> I think we usually err on the side of more concise form but I do prefer
> having () so that it's clear it's a function. Otherwise, it can look like a
> code block start & end.
>
> - R. Niwa
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Code Style: Opinion on returning void

[Zalan Bujtas]

I use this idiom too in the layout code. I guess I just prefer a more
compact code.
(I don't feel too strongly about it though)

Alan.


On Thu, Feb 7, 2019 at 7:31 PM Alex Christensen 
wrote:

> If you search for “return completionHandler” in WebKit you will find over
> a hundred instances.  Most if not all of them return void.  It means call
> the completion handler and return.  I probably wrote most of them and
> obviously think it’s a fabulous idiom.
>
> > On Feb 7, 2019, at 2:32 PM, Geoffrey Garen  wrote:
> >
> > FWIW, I’ve always felt conflicted about this case.
> >
> > I very much prefer early return to if/else chains.
> >
> > However, “return f()” when f returns void is a bit mind bending.
> >
> > So, I can’t use my preferred style in functions that return void. Boo.
> >
> > Geoff
> >
> >> On Feb 7, 2019, at 12:47 PM, Daniel Bates  wrote:
> >>
> >> Hi all,
> >>
> >> Something bothers me about code like:
> >>
> >> void f();
> >> void g()
> >> {
> >>if (...)
> >>return f();
> >>return f();
> >> }
> >>
> >> I prefer:
> >>
> >> void g()
> >> {
> >>if (...) {
> >>f();
> >>return
> >>}
> >>f();
> >> }
> >>
> >> Does it bother you? For the former? For the latter? Update our style
> guide?
> >>
> >> Opinions, please.
> >>
> >> Dan
> >> ___
> >> webkit-dev mailing list
> >> webkit-dev@lists.webkit.org
> >> https://lists.webkit.org/mailman/listinfo/webkit-dev
> >
> > ___
> > webkit-dev mailing list
> > webkit-dev@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Rounded dots in dotted border

[Zalan Bujtas]

Hi,
There’s a bit of a history here.
https://bugs.webkit.org/show_bug.cgi?id=95203
I don’t see anyone working on this issue, but Myles might have plans.
 
Zalan.
> On Jul 14, 2016, at 6:21 AM, Konstantin Tokarev  wrote:
> 
> Hello,
> 
> Document [1] says defines "dotted" style as "a series of round dots", however 
> CG and Cairo implementations draw dots as squares.
> 
> Are there any plans to implement rounded dots?
> 
> 
> [1] https://www.w3.org/TR/css3-background/#border-style
> 
> -
> 
> P.S. Some context in case anyone is interested:
> 
> I was rewriting drawLine() implementation in Qt port which was broken by 
> r177686 (remember skewed border in Bugzilla with Cairo? That thing), and 
> found that implementations of drawLine() share the same logic and differ in 
> minor details only. However, out old code was drawing rounded dots, and I 
> feel it would be more appropriate to implement this logic in shared code, or 
> drop it completely if other ports are not planning to do this.
> 
> -- 
> Regards,
> Konstantin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] MathML layout refactor proposal

[Zalan Bujtas]

It’s great to hear that MathML is getting some proper cleanup. I think the 
proposal sounds good and I am looking forward to the patches. 

Minor observation: I noticed that, since MathML block is no longer a flexbox, 
but it still needs some of the flexbox functionality, the following pattern has 
been introduced to the generic renderbox/block code. 
-if (parent()->isFlexibleBox()) {
+if (parent()->isFlexibleBox() || parent()->isRenderMathMLBlock()) {
I just wish there was another way to handle this.

Zalan.

> On Dec 9, 2015, at 3:35 AM, Alejandro Garcia Castro  wrote:
> 
> 
> Hi,
> 
> In the last months we have been working on refactoring the MathML
> layout code to make it more maintainable, because in the current point
> fixing issues or adding new features has been too complex.
> 
> We have reached the point where we think we have to discuss whether
> this work makes sense and whether it is interesting for the WebKit
> community.  If so, we will start pushing the initial patches from our
> branch to upstream.
> 
> The idea behind the refactor is to remove FlexBox dependency and
> create its own layout MathML methods. The main reasons to do this are:
> 
>   - Reduce code complexity: Adapting FlexBox layout (which is already
> complex) in order to create the MahtML layout made the code too
> complex, a big technical debt that made the improvement of MathML
> more difficult every day.
> 
>   - Avoid just another FlexBox dependent code: When we had to add
> general layout alignment support we had a lot of problems trying
> to solve some the MathML issues because it was not clear how it
> worked with the FlexBox.
> 
>   - Improve performance: We do not need all the features FlexBox
> layout adds for most of the MathML blocks but we are executing
> all that code. We also can simplify the render tree structures
> that were created to make the FlexBox layout work.
> 
>   - Make easier to improve the MathML implementation: Using
> independent renderer classes gives more flexibility to get exact
> positioning and spacing required to get high-quality math
> rendering based on TeX rules and the OpenType MATH table.  (cf
> http://www.mathml-association.org/MathMLinHTML5/)
> 
> We have a working prototype that basically passes the current MathML
> tests and removes the FlexBox dependency in:
> 
> https://github.com/alexgcastro/webkit/tree/MathMLLayout
> 
> We have basically one commit per MathML renderer that we had to
> replace. This is still initial code and we need more work and add more
> tests to make sure we are improving the situation.
> 
> We want to do it incrementally with 2 steps:
> 1. Remove FlexBox dependency but do not break the tests, this means
>   keep the RenderTree structure. This is basically done, and we just
>   need review and try to push them.
> 2. Refactor the RenderTree structure, removing the anonymous nodes
>   created to make FlexBox work and all the code that it was
>   required. We already have the Fractions and Underover implemented
>   and the code is much clearer. This will break the tests relying on
>   a PNG image or a render tree reference. Hence we will do it also
>   per renderer and rebasing the tests after each commit.
> 
> The main con of the change that the code could be bigger in some parts
> of the renderers, but more direct and simple, so it should be actually
> good regarding maintenance.
> 
> If you have any question, proposal or comment just send it, it would
> be great to hear some more feedback, and check if we should proceed
> with this effort.
> 
> Greetings,
> 
> Alex
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Proposal: Remove ENABLE(SATURATED_LAYOUT_ARITHMETIC)

[Zalan Bujtas]

Sounds good.

Zalan.
> On Nov 9, 2015, at 8:21 AM, Osztrogonác Csaba <o...@inf.u-szeged.hu> wrote:
> 
> Hi,
> 
> ENABLE(SUBPIXEL_LAYOUT) guard was removed and 
> ENABLE(SATURATED_LAYOUT_ARITHMETIC)
> is enabled on all ports more than a year ago. I don't know any issue related 
> to it.
> 
> I'd like to propose to remove the ENABLE(SATURATED_LAYOUT_ARITHMETIC) guards 
> too.
> https://bugs.webkit.org/show_bug.cgi?id=150972
> 
> Any objection?
> 
> br,
> Ossy
> 
> former thread - [webkit-dev] Proposal: Remove ENABLE(SUBPIXEL_LAYOUT)
> On 2014-08-18 22:30, Zalan Bujtas wrote:
>> Hi,
>> 
>> Quote for from bug #124234
>> "Since the SATURATED_LAYOUT_ARITHMETIC flag makes no sense without 
>> SUBPIXEL_LAYOUT, actually there is an assertion preventing this, it seems 
>> that the most sensible action is to merge the SATURATED_LAYOUT_ARITHMETIC 
>> logic into the SUBPIXEL_LAYOUT, and eventually removing it.”
>> Makes sense. I might just remove ENABLE(SATURATED_LAYOUT_ARITHMETIC) too 
>> (instead of just enable it by default).
>> 
>> Zalan.
>> 
>> On Aug 18, 2014, at 12:47 PM, Javier Fernandez <jfernan...@igalia.com> wrote:
>> 
>>> Hi,
>>> 
>>> On 08/18/2014 08:14 PM, Zalan Bujtas wrote:
>>>> Hi Everyone, I’d like to propose removing ENABLE(SUBPIXEL_LAYOUT), as
>>>> every port has it enabled. As part of this activity, I am planning to
>>>> enable SATURATED_LAYOUT_ARITHMETIC by default. Thanks, Zalan.
>>> 
>>> I've already opened a bug to address this issue, but unfortunately,
>>> didn't find the time to complete the task. See
>>> https://bugs.webkit.org/show_bug.cgi?id=124234 for details.
>>> 
>>> --
>>> javi
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] Proposal: Remove ENABLE(SUBPIXEL_LAYOUT)

[Zalan Bujtas]

Hi Everyone,
I’d like to propose removing ENABLE(SUBPIXEL_LAYOUT), as every port has it 
enabled. As part of this activity, I am planning to enable 
SATURATED_LAYOUT_ARITHMETIC by default.
Thanks,
Zalan.

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

Re: [webkit-dev] Proposal: Remove ENABLE(SUBPIXEL_LAYOUT)

[Zalan Bujtas]

Hi,

Quote for from bug #124234
Since the SATURATED_LAYOUT_ARITHMETIC flag makes no sense without 
SUBPIXEL_LAYOUT, actually there is an assertion preventing this, it seems that 
the most sensible action is to merge the SATURATED_LAYOUT_ARITHMETIC logic into 
the SUBPIXEL_LAYOUT, and eventually removing it.”
Makes sense. I might just remove ENABLE(SATURATED_LAYOUT_ARITHMETIC) too 
(instead of just enable it by default).

Zalan.

On Aug 18, 2014, at 12:47 PM, Javier Fernandez jfernan...@igalia.com wrote:

 Hi,
 
 On 08/18/2014 08:14 PM, Zalan Bujtas wrote:
 Hi Everyone, I’d like to propose removing ENABLE(SUBPIXEL_LAYOUT), as
 every port has it enabled. As part of this activity, I am planning to
 enable SATURATED_LAYOUT_ARITHMETIC by default. Thanks, Zalan.
 
 I've already opened a bug to address this issue, but unfortunately,
 didn't find the time to complete the task. See
 https://bugs.webkit.org/show_bug.cgi?id=124234 for details.
 
 --
 javi
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] S60WebKit MIME type question

[Zalan Bujtas]

One thing to look out for is that I don't thin the NPAPI is fully implemented 
on S60.
it is pretty much fully implemented on S60 AFAIK, though the API got
symbianized for some reason, by changing some data types (char*) to
Symbian types (HBufC*).

http://trac.webkit.org/browser/S60/trunk/WebKit/Plugin/inc/npapi.h

Zalan.

On Tue, Jul 14, 2009 at 5:08 PM, Jack Woottonjackwoot...@gmail.com wrote:
 Just to add, you are right, S60 browser uses ECOM to load a list of
 plugins at runtime that implement the interface
 'CEcomBrowserPluginInterface'.  It stores meta data about each plugin,
 such as the MIME type it handles and the UID of the DLL implementing
 the plugin.  The browser then loads the plugin if the MIME type found
 in the object or embed tag matches.

 One thing to look out for is that I don't thin the NPAPI is fully
 implemented on S60.

 On Tue, Jul 14, 2009 at 4:04 PM, Jack Woottonjackwoot...@gmail.com wrote:
 Plugins should follow the NPAPI
 (https://developer.mozilla.org/en/Gecko_Plugin_API_Reference) and so
 it shouldn't really matter if it pre-dates WebKit.  No doubt someone
 else on this mailing list can offer more help here (since I'm new to
 webkit).

 If you sign up to the Symbian Foundation, then you can browse S60 code
 online.  Unfortunately having had a quick look it seems there are no
 reference plugin implementations in the code.  There are some s60
 specific plugin files, using the Symbian Foundation cross referencing
 tool, they can be found in:

 /MCL/sf/mw/web/webengine/osswebengine/WebKit/s60/plugins
 (http://developer.symbian.org/xref/oss/xref/MCL/sf/mw/web/webengine/osswebengine/WebKit/s60/plugins/)

 On Tue, Jul 14, 2009 at 3:35 PM, Sam Critchleyscritch...@gypsii.com wrote:

 Hi Jack,

 Thanks for taking the time to reply. The Nokia Platform Services resources
 are great, but currently only available in WRT on their S60 5th edition
 devices (5800 and N97). I think we're also going to look closely at the
 plug-in route as well - I wonder if there's a repository of standard
 plug-ins somewhere...

 I found the following on S60 browser plug-ins:

 http://www.forum.nokia.com/main/resources/technologies/browser_plug-in_api.html

 Unfortunately I think this pre-dates the WebKit browser, so I'm not sure it
 still applies

 I did find some documentation on Ecom plug-ins as well. I assume that's also
 available through S60WebKit as well. The main question is whether there's a
 repository of existing plug-ins somewhere (e.g. if there's a camera plug-in)
 or if you have to code your own.

 Thanks,

 Sam


 On Jul 14, 2009, at 2:46 PM, Jack Wootton wrote:

 If a browser finds a MIME type it cannot display (for example from an
 embed or object tag) then is will iterate through available
 plugins and load the plugin which handles that MIME type.

 Regarding camera on S60, you may want to take a look at:

 Nokia hvave released a beta version of the their new Platform
 Services (JavaScript API to you and me), this includes a camera API
 (the download includes a sis file which adds the new api to the
 device, but it also comes with a JavaScript library which allows
 pictures to be taken using the camera app and displayed using
 JavaScript).  There are also sample widgets which use the camera API.


 http://www.forum.nokia.com/info/sw.nokia.com/id/cccea743-f4e5-418f-ad9f-0a7a7f50868f/Nokia_Platform_Services_2_0.html

 For something which isn't in beta, Nokia provide a JavaScript API for
 launching 3rd party applications (you just supply the UID of the app
 you wish to launch - I don't know how you can transfer data from the
 app to the webkit environment though).  The API is part of Nokia's Web
 Developer Library found here:


 http://library.forum.nokia.com/index.jsp?topic=/Web_Developers_Library/GUID-4D13AF3F-4733-44E7-996F-F27A11C9D6BF_cover.html

 You want to look at Web Developer's Library 1.7  Web Runtime widgets

 Developing widgets  Web Runtime API reference  JavaScript Service

 API reference

 On Tue, Jul 14, 2009 at 1:21 PM, Sam Critchleyscritch...@gypsii.com
 wrote:

 Hi,

 Apologies for the very basic question, but I'm trying to find out how you
 can use custom MIME types in WebKit on S60 (3rd and 5th editions). We're
 looking at doing something like triggering the S60 camera app using a
 camera
 button in a web form (which is accessed in an app using Webkit for
 content
 display), take a picture, insert it into the form, and POST it to the
 website. Can anyone point me to information on how/whether we could do
 this?

 Thanks,

 Sam


 ***
 Sam Critchley
 VP, Products and Co-Founder
 GyPSii
 http://www.gypsii.com/
 scritch...@gypsii.com
 GyPSii HQ Amsterdam
 Mobile: +31 6 28 233 133
 Landline: +31 20 715 5915
 Fax: +31 20 524 8896
 Join the GyPSii mobile lifestyle
 Download GyPSii to your phone
 Latest GyPSii Place
 ***






 ___
 webkit-dev 

Re: [webkit-dev] Canvas API in Webkit

[Zalan Bujtas]

 Well, those browsers aren't open source, so there's no real way for you to
 find out how they implemented the feature.

 I think it's safe to assume that they draw the web pages into a bitmap and
 then shrink the image.

 It certainly has nothing to do with the HTML canvas element in either
 case.

-- Darin
The function below indicates that s60 browser is using a bitmap to
implement the history feature.

void CHistoryController::UpdateHistoryEntryThumbnailL(const
CFbsBitmap* aBitmap);
http://trac.webkit.org/browser/S60/trunk/HistoryProvider/inc/HistoryController.h#L190

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

[webkit-dev] We are porting WebKit to UIQ (Symbian based platform)

[Zalan Bujtas]

Hi,
Ozone team has been porting WebKit to UIQ platform and the first, alpha
version is available at http://www.o3mobi.com It is based on r34485
(06/10/08).

For us, it is important to make sure that our port takes advantage of all
the improvements coming to WebKit trunk, so for this reason, we'd like to
merge our changes back, rather than having it forked.

Thanks,
Zalan Bujtas / Ozone team.

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

Re: [webkit-dev] errors in Carbide but not on command line

[Zalan Bujtas]

 This seems simple enough and, I can just remove the line '#include
 domain/osextensions/platform_paths.hrh'.

 However, in the JavaScriptCore bld.inf it looks likes this:
The targeted sdk (s60 3rd edition) cannot resolve
MW_LAYER_SDK_EXPORT_PATH, so the export paths are hardcoded. That's
the major difference between the #ifndef and the #else branch. I think
you need to clean up the .inf files by removing the #ifndef
__BROWSER_SDK' branch.

 How can Nokia port the webkit so that it doesn't build in their own IDE?
I guess, Webkit was ported to S60 before, Carbide was taken into use
and not been updated since.

Zalan.

On Thu, Jul 17, 2008 at 11:58 AM, Jack Wootton [EMAIL PROTECTED] wrote:
 Does anyone have a solution other than just commenting out all the
 files that shouldn't be included?  This doesn't seem practical since
 there are around 60 errors reported from files not being found, it
 seems these files are meant to be conditionally included in the build
 process but that the '#ifndef __BROWSER_SDK' preprocessor commands are
 not working.

 On Thu, Jul 17, 2008 at 10:38 AM, Jack Wootton [EMAIL PROTECTED] wrote:
 OK, So from reading this

 http://discussion.forum.nokia.com/forum/showthread.php?t=69737

 I understand the situation better.  One question:

 How can Nokia port the webkit so that it doesn't build in their own IDE?

 People moan about Google this and Google that, but this is something
 Google would never do.

 On Thu, Jul 17, 2008 at 9:50 AM, Jack Wootton [EMAIL PROTECTED] wrote:
 Hi,

 The WebKit bld.inf contains the following lines:

 #ifndef __BROWSER_SDK
 #include domain/osextensions/platform_paths.hrh
 #endif

 This seems simple enough and, I can just remove the line '#include
 domain/osextensions/platform_paths.hrh'.

 However, in the JavaScriptCore bld.inf it looks likes this:

 /** Start horrible code extract */

 #ifndef __BROWSER_SDK
 #include domain/osextensions/platform_paths.hrh
 ..\kjs\internal.h 
 MW_LAYER_SDK_EXPORT_PATH(javascriptcore\internal.h)
 ..\kjs\interpreter.h  
 MW_LAYER_SDK_EXPORT_PATH(javascriptcore\interpreter.h)
 ..\kjs\object.h   MW_LAYER_SDK_EXPORT_PATH(javascriptcore\object.h)
 ..\kjs\protect.h  MW_LAYER_SDK_EXPORT_PATH(javascriptcore\protect.h)
 ..\kjs\stdint.h   MW_LAYER_SDK_EXPORT_PATH(javascriptcore\stdint.h)

 ..\bindings\npruntime.h
 MW_LAYER_SDK_EXPORT_PATH(javascriptcore\npruntime.h)
 ..\bindings\npruntime_impl.h
 MW_LAYER_SDK_EXPORT_PATH(javascriptcore\npruntime_impl.h)
 ..\bindings\npruntime_priv.h
 MW_LAYER_SDK_EXPORT_PATH(javascriptcore\npruntime_priv.h)
 ..\bindings\runtime.h
 MW_LAYER_SDK_EXPORT_PATH(javascriptcore\runtime.h)
 ..\bindings\runtime_object.h
 MW_LAYER_SDK_EXPORT_PATH(javascriptcore\runtime_object.h)
 ..\bindings\runtime_root.h
 MW_LAYER_SDK_EXPORT_PATH(javascriptcore\runtime_root.h)
 ..\bindings\NP_jsobject.h
 MW_LAYER_SDK_EXPORT_PATH(javascriptcore\NP_jsobject.h)
 ..\bindings\c\c_utility.h
 MW_LAYER_SDK_EXPORT_PATH(javascriptcore\c_utility.h)
 #else
 ..\kjs\internal.h \epoc32\include\oem\javascriptcore\internal.h
 ..\kjs\interpreter.h  \epoc32\include\oem\javascriptcore\interpreter.h
 ..\kjs\object.h   \epoc32\include\oem\javascriptcore\object.h
 ..\kjs\protect.h  \epoc32\include\oem\javascriptcore\protect.h
 ..\kjs\stdint.h   \epoc32\include\oem\javascriptcore\stdint.h

 ..\bindings\npruntime.h
 \epoc32\include\oem\javascriptcore\npruntime.h
 ..\bindings\npruntime_impl.h
 \epoc32\include\oem\javascriptcore\npruntime_impl.h
 ..\bindings\npruntime_priv.h
 \epoc32\include\oem\javascriptcore\npruntime_priv.h
 ..\bindings\runtime.h
 \epoc32\include\oem\javascriptcore\runtime.h
 ..\bindings\runtime_object.h
 \epoc32\include\oem\javascriptcore\runtime_object.h
 ..\bindings\runtime_root.h
 \epoc32\include\oem\javascriptcore\runtime_root.h
 ..\bindings\NP_jsobject.h
 \epoc32\include\oem\javascriptcore\NP_jsobject.h
 ..\bindings\c\c_utility.h
 \epoc32\include\oem\javascriptcore\c_utility.h
 #endif //#ifndef __BROWSER_SDK

 /** End horrible code extract */

 So, presumably it's the first section that needs to go, but can all of
 it be removed, or just the offending line

 '#include domain/osextensions/platform_paths.hrh'

 ?





 On Wed, Jul 16, 2008 at 6:19 PM, Zalan Bujtas [EMAIL PROTECTED] wrote:
#include domain/osextensions/platform_paths.hrh
 it is #ifdef-ed out in the bld.inf. Carbide does not manage #ifdefs in
 the build files properly.

 Zalan.

 On Wed, Jul 16, 2008 at 12:41 PM, Jack Wootton [EMAIL PROTECTED] wrote:
 To add, the following two files are displaying errors in Carbide:

 S60\JavaScriptCore\group\bld.inf
 S60\WebKit\group\bld.inf

 JavaScriptCore bld.inf both have a problem with the following line:

 #include domain/osextensions/platform_paths.hrh

 Presumably it can't find the file.



 On Wed, Jul 16, 2008 at 5:11 PM, Jack Wootton [EMAIL PROTECTED] wrote:
 Hi all

Re: [webkit-dev] errors in Carbide but not on command line

[Zalan Bujtas]

#include domain/osextensions/platform_paths.hrh
it is #ifdef-ed out in the bld.inf. Carbide does not manage #ifdefs in
the build files properly.

Zalan.

On Wed, Jul 16, 2008 at 12:41 PM, Jack Wootton [EMAIL PROTECTED] wrote:
 To add, the following two files are displaying errors in Carbide:

 S60\JavaScriptCore\group\bld.inf
 S60\WebKit\group\bld.inf

 JavaScriptCore bld.inf both have a problem with the following line:

 #include domain/osextensions/platform_paths.hrh

 Presumably it can't find the file.



 On Wed, Jul 16, 2008 at 5:11 PM, Jack Wootton [EMAIL PROTECTED] wrote:
 Hi all,

 Having successfully built S60 WebKit on the command line (using an
 older version (21772 )), I decided to try building it in Carbide. I
 get the following errors:

 /** Start Errors
 **/

 In file included from .\BLD.INF:50:
 .\.\JavaScriptCore\group\bld.inf:28:
 domain/osextensions/platform_paths.hrh: No such file or directory

 In file included from .\BLD.INF:52:
 .\.\WEBKIT\group\bld.inf:42: domain/osextensions/platform_paths.hrh:
 No such file or directory
 BLDMAKE ERROR: ERROR: cpp.exe returned non-zero exit status (8448)
cpp.EXE -undef -nostdinc -+  -I ..\epoc32\include -I . -I .\  -I
 ..\epoc32\include\variant -include
 ..\epoc32\include\variant\Symbian_OS_v9.1.hrh .\BLD.INF

 /** End Errors
 **/

 The build target inside Carbide was set to Emulator Debug (WINSCW).

 Can anyone help?

 --
 Regards
 Jack




 --
 Regards
 Jack
 ___
 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