Re: [webkit-dev] Heads up: Incremental build issue on cmake (GTK/EFL) ports

[Gyuyoung Kim]

Hello Ossy,

Thank you. I also restart efl ews with clean build.

Gyuyoung

On Thursday, August 7, 2014, Osztrogonác Csaba  wrote:

> Of course, I used the "Force Clean build" checkbox on
> build.webkit.org as you mentioned. ;) So the buildbots
> are happy now.
>
> I sent this mail to let the developers know what should
> they do if they run into this problem on local builds.
>
> But unfortunately we aren't able to clean the EFL EWS,
> only its maintainer can do it. Gyuyoung, could you kick
> this bot please? (It seems GTK guys already fixed their EWS)
>
> br,
> Ossy
>
> Ryosuke Niwa írta:
>
>> You should be able to trgger clean builds on build.webkit.org <
>> http://build.webkit.org> once you login.  Or are you talking about
>> downstream bots GTK/EFL bots?
>>
>> On Wednesday, August 6, 2014, Osztrogonác Csaba > > wrote:
>>
>> Hi,
>>
>> r171961 changed the path of the generated inspector files (because
>> of r171942) from WebKitBuild/Release/__DerivedSources/JavaScriptCore
>> to WebKitBuild/Release/__DerivedSources/JavaScriptCore/__inspector
>>
>> But unfortunately the old generated files remained in the old
>> path which caused the following strange incremental build error
>> after r172129:
>>
>> In file included from
>> /home/oszi/webkit/Source/__JavaScriptCore/inspector/__
>> agents/InspectorAgent.h:35:0,
>>  from
>> /home/oszi/webkit/Source/__JavaScriptCore/inspector/__
>> JSGlobalObjectInspectorControl__ler.cpp:35:
>> /home/oszi/webkit/WebKitBuild/__Release/DerivedSources/__
>> JavaScriptCore/__InspectorJSBackendDispatchers.__h:89:18:
>> note:virtual void
>> Inspector::__InspectorRuntimeBackendDispatc__herHandler::__
>> getRuntimeTypeForVariableInTex__tRange(Inspector::ErrorString*__,
>> const WTF::String&, const WTF::String&, int, int, int, int,
>> WTF::String*)
>>
>> To solve this problem, you should simple remove the following files
>> from WebKitBuild/Release/__DerivedSources/JavaScriptCore:
>> InspectorJSBackendDispatchers.__cpp
>> InspectorJSBackendDispatchers.__h
>> InspectorJSFrontendDispatchers__.cpp
>> InspectorJSFrontendDispatchers__.h
>> InspectorJSTypeBuilders.cpp
>> InspectorJSTypeBuilders.h
>>
>> I triggered clean build on the buildbots to fix this issue, but
>> these files should be removed on the GTK and EFL EWS bots too.
>>
>> br,
>> Ossy
>> _
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/__mailman/listinfo/webkit-dev
>> 
>>
>>
>>
>> --
>> Ryosuke Niwa
>>
>>
>>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>


-- 
Sent from Gyuyoung Iphone
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Heads up: Incremental build issue on cmake (GTK/EFL) ports

[Osztrogonác Csaba]

Of course, I used the "Force Clean build" checkbox on
build.webkit.org as you mentioned. ;) So the buildbots
are happy now.

I sent this mail to let the developers know what should
they do if they run into this problem on local builds.

But unfortunately we aren't able to clean the EFL EWS,
only its maintainer can do it. Gyuyoung, could you kick
this bot please? (It seems GTK guys already fixed their EWS)

br,
Ossy

Ryosuke Niwa írta:
You should be able to trgger clean builds on build.webkit.org 
 once you login.  Or are you talking about 
downstream bots GTK/EFL bots?


On Wednesday, August 6, 2014, Osztrogonác Csaba > wrote:


Hi,

r171961 changed the path of the generated inspector files (because
of r171942) from WebKitBuild/Release/__DerivedSources/JavaScriptCore
to WebKitBuild/Release/__DerivedSources/JavaScriptCore/__inspector

But unfortunately the old generated files remained in the old
path which caused the following strange incremental build error
after r172129:

In file included from

/home/oszi/webkit/Source/__JavaScriptCore/inspector/__agents/InspectorAgent.h:35:0,
 from

/home/oszi/webkit/Source/__JavaScriptCore/inspector/__JSGlobalObjectInspectorControl__ler.cpp:35:

/home/oszi/webkit/WebKitBuild/__Release/DerivedSources/__JavaScriptCore/__InspectorJSBackendDispatchers.__h:89:18:
note:virtual void

Inspector::__InspectorRuntimeBackendDispatc__herHandler::__getRuntimeTypeForVariableInTex__tRange(Inspector::ErrorString*__,
const WTF::String&, const WTF::String&, int, int, int, int,
WTF::String*)

To solve this problem, you should simple remove the following files
from WebKitBuild/Release/__DerivedSources/JavaScriptCore:
InspectorJSBackendDispatchers.__cpp
InspectorJSBackendDispatchers.__h
InspectorJSFrontendDispatchers__.cpp
InspectorJSFrontendDispatchers__.h
InspectorJSTypeBuilders.cpp
InspectorJSTypeBuilders.h

I triggered clean build on the buildbots to fix this issue, but
these files should be removed on the GTK and EFL EWS bots too.

br,
Ossy
_
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/__mailman/listinfo/webkit-dev




--
Ryosuke Niwa




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

[webkit-dev] Is there a (JavaScript) to test out WebUIDelegate?

[Daryle Walker]

I’m trying out Cocoa with a mini web-browser project.  My document class 
holding a WebView object implements the WebUIDelegate informal protocol.  I 
could test out webView:createWebViewWithRequest: by visiting a page that sends 
all links to a new window/tab.  Twitter is a good example of this.  It was a 
pain finding a page with Javascript-generated messages to the status bar, 
needed to test webView:setStatusText:.  Is there a JavaScript test suite so I 
can try triggering any of the other WebUIDelegate calls.  So far I need:

//=
- (WebView *)webView:(WebView *)sender createWebViewWithRequest:(NSURLRequest 
*)request;  // click links on Twitter
- (void)webViewShow:(WebView *)sender;  // need a case that doesn’t call 
webView:createWebViewWithRequest: first
- (void)webView:(WebView *)sender setStatusText:(NSString *)text;  // went to a 
JavaScript demo on status-bar messages
- (NSString *)webViewStatusText:(WebView *)sender;
- (BOOL)webViewIsStatusBarVisible:(WebView *)sender;
- (void)webView:(WebView *)sender setStatusBarVisible:(BOOL)visible;
//=

I need a way to test the second function since it and the first function are 
usually called together, but my implementation of the first function 
automatically calls its own version of the second.  So I need a way to call the 
second function by itself.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

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

[webkit-dev] ftlopt merge - basically done

[Filip Pizlo]

Hi everyone,

The JSC “ftlopt” branch is basically merged.  I think I have one more revision 
to merge over, and it is a minor one.  Please don’t land more things on the 
branch.  Landing on trunk is fine; it’s unlikely to get in my way as I merge 
the last revision over.

Thanks to everyone who helped with diagnostic problems and fixing things!

-Filip

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

Re: [webkit-dev] FeatureDefines.h and .xcconfig

[Alex Christensen]

I’ve run into similar issues.  I’m working on building the Apple ports with 
CMake.  I would be in favor of switching everything to the xcconfig files, but 
please don’t forget to edit Source/cmake/OptionsMac.cmake.  Now we have 5 files 
to edit, but hopefully I’ll get that down to 1 when I’m done :)

Alex

On Aug 6, 2014, at 2:22 PM, Dean Jackson  wrote:

> Hi floks,
> 
> Things are a bit confusing in the OS X and iOS build configurations because 
> we have both a FeatureDefines.h and a set of .xcconfig files, often defining 
> the same thing, and sometimes inconsistently (or at least I've made the 
> mistake of turning a feature off in one place when the other place turned it 
> back on).
> 
> Obviously it would be good to have only one location for feature enabling.
> 
> While FeatureDefines.h says "Use this file to list _all_ ENABLE() macros" it 
> also says "The feature defaults in this file are only taken into account if 
> the (port specific) build system has not enabled or disabled a particular 
> feature", which is not true.
> 
> My proposal is to stop using FeatureDefines.h for the Apple ports (*) and 
> move completely to .xcconfig files. 
> 
> Notes:
> 
> - Some scripts launched by Xcode might use the ENABLE_WHATEVER environment 
> variables (which FeatureDefines.h can't provide)
> 
> - The xcconfig files will probably have to be of the form ENABLE_WHATEVER=0 
> to disable a feature, rather than just leaving it blank.
> 
> - We'd have to change from #ifdef to #if in places.
> 
> - You'd always have to edit 4 files to toggle a feature :(
> 
> - Generating the FeatureDefines.xcconfig from FeatureDefines.h might be cool, 
> but we have a fair amount of release-specific logic in there (e.g. only 
> enabled on 10.9).
> 
> Is this a terrible idea? Please suggest a better one!
> 
> Dean
> 
> (*) I think Apple's Windows port should probably continue with 
> FeatureDefines.h because it doesn't use Xcode.
> ___
> 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] FeatureDefines.h and .xcconfig

[Dean Jackson]

Hi floks,

Things are a bit confusing in the OS X and iOS build configurations because we 
have both a FeatureDefines.h and a set of .xcconfig files, often defining the 
same thing, and sometimes inconsistently (or at least I've made the mistake of 
turning a feature off in one place when the other place turned it back on).

Obviously it would be good to have only one location for feature enabling.

While FeatureDefines.h says "Use this file to list _all_ ENABLE() macros" it 
also says "The feature defaults in this file are only taken into account if the 
(port specific) build system has not enabled or disabled a particular feature", 
which is not true.

My proposal is to stop using FeatureDefines.h for the Apple ports (*) and move 
completely to .xcconfig files. 

Notes:

- Some scripts launched by Xcode might use the ENABLE_WHATEVER environment 
variables (which FeatureDefines.h can't provide)

- The xcconfig files will probably have to be of the form ENABLE_WHATEVER=0 to 
disable a feature, rather than just leaving it blank.

- We'd have to change from #ifdef to #if in places.

- You'd always have to edit 4 files to toggle a feature :(

- Generating the FeatureDefines.xcconfig from FeatureDefines.h might be cool, 
but we have a fair amount of release-specific logic in there (e.g. only enabled 
on 10.9).

Is this a terrible idea? Please suggest a better one!

Dean

(*) I think Apple's Windows port should probably continue with FeatureDefines.h 
because it doesn't use Xcode.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Questions about ports

[Tim Horton]

> On Aug 5, 2014, at 23:48, Jacques-Olivier  wrote:
> 
> Hi everyone,
> 
> I have a couple of questions regarding the different ports of WebKit:
> 
> 1) I suppose the port used by Safari Mac OS X is the Apple’s mac port (built 
> by default)
> Is there a planing of when a version of WebKit is being publicly released in 
> Safari Mac?

There is, of course, but said planning does not occur in public.

> 2) Which port is being used by Safari iOS and how to build it?

The iOS port is integrated into WebKit trunk. You’ll see lots of PLATFORM(IOS) 
around.

> Is there a release planning?

Not publicly, same as Mac.

> What is the flag to build this port?
> How to test it?

It is not currently possible for third parties to build/test this port.

> 3) Which port is being used to power third party applications on iOS? and how 
> to build it?
> Is there a release planning?
> What is the flag to build this port?
> How to test it?

All the same as above.

> Regards,
> J-O H
> 
> --
> Haché Jacques-Olivier
> R&D Engineer at Temasys Communications Pte Ltd
> Fr : 06 45 85 48 80
> Sg : 9086 3673 
> 
> ___
> 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] Heads up: Incremental build issue on cmake (GTK/EFL) ports

[Osztrogonác Csaba]

Hi,

r171961 changed the path of the generated inspector files (because
of r171942) from WebKitBuild/Release/DerivedSources/JavaScriptCore
to WebKitBuild/Release/DerivedSources/JavaScriptCore/inspector

But unfortunately the old generated files remained in the old
path which caused the following strange incremental build error
after r172129:

In file included from 
/home/oszi/webkit/Source/JavaScriptCore/inspector/agents/InspectorAgent.h:35:0,
 from 
/home/oszi/webkit/Source/JavaScriptCore/inspector/JSGlobalObjectInspectorController.cpp:35:
/home/oszi/webkit/WebKitBuild/Release/DerivedSources/JavaScriptCore/InspectorJSBackendDispatchers.h:89:18: 
note: 	virtual void 
Inspector::InspectorRuntimeBackendDispatcherHandler::getRuntimeTypeForVariableInTextRange(Inspector::ErrorString*, 
const WTF::String&, const WTF::String&, int, int, int, int, WTF::String*)


To solve this problem, you should simple remove the following files
from WebKitBuild/Release/DerivedSources/JavaScriptCore:
InspectorJSBackendDispatchers.cpp
InspectorJSBackendDispatchers.h
InspectorJSFrontendDispatchers.cpp
InspectorJSFrontendDispatchers.h
InspectorJSTypeBuilders.cpp
InspectorJSTypeBuilders.h

I triggered clean build on the buildbots to fix this issue, but
these files should be removed on the GTK and EFL EWS bots too.

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

Re: [webkit-dev] Questions about ports

[Benjamin Poulain]

On 8/5/14, 11:48 PM, Jacques-Olivier wrote:
> I have a couple of questions regarding the different ports of WebKit:
> 
> 1) I suppose the port used by Safari Mac OS X is the Apple’s mac port
> (built by default)
> Is there a planing of when a version of WebKit is being publicly
> released in Safari Mac?

Each port can decide to branch WebKit trunk at any time to stabilize a
release version.

As far as I know, only WebKitGTK makes public announcements of their
release plans, bug targets, etc.

About Safari Mac, it is branched off WebKit trunk like any other port.
There is no public announcement of the release plans.

> 2) Which port is being used by Safari iOS and how to build it?
> Is there a release planning?
> What is the flag to build this port?
> How to test it?

iOS Safari uses the iOS port (flag PLATFORM(IOS)). It shares a lot of
code with OS X, iOS and OS X are very similar platforms.

You do not need to build for it or run the tests, this is done by Apple.
For now, work in the WebKit project really focuses on OSX/GTK/EFL/Windows.

> 3) Which port is being used to power third party applications on iOS?
> and how to build it?
> Is there a release planning?
> What is the flag to build this port?
> How to test it?

There is not a separate WebKit for Safari and third party apps, the same
WebKit is used for both.

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