On 2/7/16, Konstantin Tokarev <annu...@yandex.ru> wrote: > Please try updated version of my branch, it now does not use LLVM unless you > enable USE_LLVM_DISASSEMBLER.
I merged your branch. That seemed to build and work. So what would USE_LLVM_DISAAEMBLER get me if I could build it? Also, are there things I can do to shrink JavaScriptCore? It's now over 20MB. I know ICU is a big part of that, but JSC itself seems to keep getting bigger too. To respond to a prior suggestion about ICU size, I am familiar with the data archive option. However, there are several challenges with that: - I don't know what parts JSC actually needs to know what I can safely remove - I don't know how ICU/JSC load the data archive. Android APK file semantics are pretty terrible and you have to send around a Java AsssetManager to access everything. Standard file library calls don't 'just work'. - I really need to build as a static library because since it is a private implementation detail of JSC. There are problems if somebody downstream of me wants to use ICU, with a potentially different version. If I dynamically link and use data archives, I open up a lot of conflict issues. Similarly, Android itself may use ICU internally and I've been warned of conflict problems by others. Static linking avoids these headaches. Also, I haven't figured out if data archive and static libraries are compatible. - I did notice Apple has a modified, stripped down version of ICU as part of Darwin. I was unable to figure out how to get it built. It was a pretty complicated Makefile. Thanks, Eric P.S. Here is an indentation fix for my previous ICU patch. https://github.com/ewmailing/webkit/commit/e2c94e8b126143402b4e17cc514c4df412de5ace _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
