Re: [webkit-dev] Proposal: Remove ENABLE(SVG)
Not a true statement if you consider out of tree ports. None of the ports we have done at Crank have used or needed svg support and as embedded systems, they all benefit from the smaller footprint. Thanks, Thomas - Reply message - From: Sam Weinig wei...@apple.com To: webkit-dev@lists.webkit.org Development webkit-dev@lists.webkit.org Subject: [webkit-dev] Proposal: Remove ENABLE(SVG) Date: Tue, Jan 28, 2014 18:13 Hi Everyone, While we are discussing removing #ifdefs that everyone has enabled, I’d like to propose removing ENABLE(SVG), as every port has SVG enabled. The only argument I have heard for keeping it around is to keep a “minimal build” working, but I don’t think the clutter of the #ifdefs is worth that. -Sam ___ 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] Announcing new port: Nix
Geoffrey Garen wrote: Sure. We at University of Szeged who work on WebKitNix from this year contributed many fixes to various part of WebKit: JavaScriptCore, WebCore, Tools, … Thank you for this list. I started reading through it, but I noticed a high percentage of patches that were port-specific build fixes or port-specific features like support for legacy ARM chips. For example, “...on ARM traditional” (https://trac.webkit.org/changeset/142616). Those patches are cost to core WebKit development, not benefit. I don't want to mis-interpret your statement here. Can you clarify what you mean by Those patches are cost to core WebKit development, not benefit. Thanks, Thomas ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Announcing new port: Nix
Oliver Hunt wrote: On Sep 12, 2013, at 6:38 AM, Thomas Fletchertho...@cranksoftware.com wrote: TDLR: Crank Software Supports a NIX port This is a question of maintenance burden. As Geoff said every port adds a cost to developing and maintaining webkit. You've said you support a NIX port, but a quick search doesn't show any contributions from you or crank software (very quick so feel free to correct me if i'm wrong) so it's hard to see what this support entails. As I mentioned in my post, most of the work that we have done for our customers entails bringing WebKit into embedded systems for custom products with custom CPU's and custom rendering technologies. These are generally not re-contributable items because they are not generally accessible to others outside of a very specific domain. Additionally, we work on slimming down and removing features from WebKit so that it can operate in these environments more effectively. Discussions on this list have shown repeatedly that the WebKit community is not interested in 'notching out' functionality (ie adding ENABLE'ments) to make the project more customizable since it potentially diminishes the WebKit brand. Fair enough, that's the project's position. Our support at the moment can be nothing more than ideological, however should an NIX port become mainstream then it would provide us with a public avenue to direct our energies towards since most of the ports that we have done would align well with using NIX as a base. While I am not at liberty to disclose our complete customer base, I can say that we have been working since 2008 with WebKit initially using the OWB fork then moving to mainstream WebKit as the OWB work folded. Our customer's include automotive OEM and Tier 1 suppliers, consumer electronics producers, set-top box and gaming console device manufactures. True .. you won't see a log of commits from @cranksoftware.com but we are here and have a significant body of WebKit customization expertise. Thomas ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] compact ICU unicode
What if we created a new project, based off of ICU called lilICU .. would the WebKit community then accept an alternative binding to this new library? Not to split hairs, but that is essentially what it seems that we would have to do, create a new library, before the WebKit community becomes interested in ways of trimming down WebKit for embedded devices where the resource impositions of dependent libraries are significant. Having worked at porting WebKit to a variety of embedded platforms over the last five years (most of the work non-recontributable due to lack of interest in esoteric and non-mainstream platforms) the size of a typical WebKit build has grown significantly while the number of tuning options has decreased. Thanks, Thomas Glenn Adams wrote: On Sat, Jun 8, 2013 at 3:15 AM, Salisbury, Mark mark.salisb...@hp.com mailto:mark.salisb...@hp.com wrote: Hello, What would people think about including specific ICU data tables in WTF in order to provide a lightweight (but functional) unicode implementation? FWIW, I'd suggest you port ICU to your platform or if the size is too large, port the portion of it that WK uses, and then use that portion. However, I think the ICU library or even a subset should NOT be added to WTF. On embedded systems the size of ICU is prohibitive. Determining the right way to package it to make it small enough isn't simple either. A patch was reviewed once that attempted to add ICU data tables directly in WTF and there were two concerns: 1) Checking in generated files (https://bugs.webkit.org/show_bug.cgi?id=27305#c8) 2) Questions concerning if the ICU license is compatible with WebCore (https://bugs.webkit.org/show_bug.cgi?id=27305#c9) I believe the patch could be done differently as to not check in generated files. Regarding the second concern, ICU has a very permissive license (http://www.icu-project.org/repos/icu/icu/trunk/license.html). There are three requirements, basically that the copyright and permission notice has to appear with copies of the software. I believe that is already a requirement for distributions of webkit that use ICU. Except for WChar unicode, I believe all webkit builds now use ICU Unicode. This Unicode path could replace WCHAR_UNICODE or be introduced as a third option, call it what you like - BASIC_ICU_UNICODE, ICU_LITE_UNICODE, COMPACT_ICU_UNICODE, etc.. I think it might be valuable for other ports that are size conscious - the up and coming NIX port comes to mind. Thanks, Mark Background: After rebasing my WinCE port of webkit, I ran into an ASSERT in WebCore/platform/text/wchar/TextBreakIteratorWchar.cpp, acquireLineBreakIterator(). I thought I'd be able to easily fix this, since I had already modified how LineBreakIterator works to take prior context into account (on my own branch) and find line break in a stream of non-ASCII characters. However, the WCHAR Unicode implementation is very bare bones and does not even support returning the Unicode character category (http://trac.webkit.org/browser/trunk/Source/WTF/wtf/unicode/wchar/UnicodeWchar.cpp#L35). WCHAR Unicode was originally called WinCE Unicode, then it was properly renamed as it had nothing to do with WinCE. WinCE Unicode originally came in here: https://bugs.webkit.org/show_bug.cgi?id=27305. The reason it was introduced was to save space (filesystem and RAM). ICU, if not packaged very carefully (http://userguide.icu-project.org/packaging), is actually larger than webkit itself. On embedded systems, this is a big deal. The original plan with the bug above was to include specific ICU data tables in webkit. I've been compiling WTF with Unicode tables embedded for some time now. I don't believe I've seen many layout test regressions due to using a simplified ICU implementation. ___ webkit-dev mailing list webkit-dev@lists.webkit.org mailto: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] CMake for Apple's Windows port
I will say Thank You ... we use cmake as the base for nearly every new WebKit port we engage in. We have a native Windows build that is cmake to replace the Apple/CF based one and it is so much easier to maintain than the previous collection of VS property pages and build configurations. Not only that but we can quickly generate multiple build variants (CF vs GDI for example) very quickly and also share project content in ways that make sense (such as with WinCE). We can count at least 6 ports we have done using cmake. We have rolled our own a couple of times on early ports, but on the last few with the 'in tree' initial base from WinCE and EFL we're now using that as a basis. So Patrick (and whomever else kicks in keeping the cmake builds running) ... THANK YOU. Thomas - Crank Software Inc. Office: 613-595-1999 x511 Mobile: 613-878-4659 Online: www.cranksoftware.com http://www.cranksoftware.com/ Check out: Crank Software¹s Blog http://cranksoftware.com/blog/ There is a better way to build user interfaces for embedded devices. Download a 30 day evaluation http://www.cranksoftware.com/products/eval.php of Crank Storyboard Suite today From: Patrick Gansterer par...@paroga.com Date: Thu, 19 Apr 2012 03:43:28 +0200 To: Mark Rowe mr...@apple.com Cc: Dirk Pranke dpra...@chromium.org, WebKit Development webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] CMake for Apple's Windows port Am 12.04.2012 um 20:06 schrieb Dirk Pranke: Patrick, have you documented what all you need to install on a Win box in order to be able to run CMake and do the build? You need to install CMake and the same tools listed at http://trac.webkit.org/wiki/WinCE#Build and http://www.webkit.org/building/tools.html (but without cygwin). Am 12.04.2012 um 23:47 schrieb Mark Rowe: On 2012-04-12, at 14:28, Dirk Pranke dpra...@chromium.org wrote: Interesting. Can you comment further on why this is needed, instead of just checking out the whole repo? The short answer is that doing so would violate internal policies that we have about what sorts of files are acceptable in the source of production builds (for example, precompiled libraries are not acceptable). We also don't have any desire to shuffle multiple gigabytes of layout tests around machines that are only used for building. Is it possible to get a (detailed) list of requirements? It's hard for people don't knowing the internal Apple build process to work on it. Why isn't it possible to checkout only the Source directory? Since the current system has more than 1 VS solution too, I don't think it will be a problem to have more than one root CMakeLists.txt too. Is there a interest in getting rid of the Visual Studio files? Are there any points agains CMake we know already? I don't want to put (much) work into the CMake files for a simple No, thanks at the end. ;-) -- Patrick ___ 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
