[webkit-dev] Questions about ports
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? 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? 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? Regards, J-O H -- Haché Jacques-Olivier RD 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
Re: [webkit-dev] Questions about ports
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
[webkit-dev] Heads up: Incremental build issue on cmake (GTK/EFL) ports
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
On Aug 5, 2014, at 23:48, Jacques-Olivier jo.ha...@temasys.com.sg 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 RD 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] FeatureDefines.h and .xcconfig
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] FeatureDefines.h and .xcconfig
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 d...@apple.com 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] ftlopt merge - basically done
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
[webkit-dev] Is there a (JavaScript) to test out WebUIDelegate?
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
