01.02.2016, 15:21, "Konstantin Tokarev" <[email protected]>: > 01.02.2016, 02:22, "Eric Wing" <[email protected]>: >> On 1/1/16, Konstantin Tokarev <[email protected]> wrote: >>> 01.01.2016, 12:46, "Yusuke SUZUKI" <[email protected]>: >>>> Hi, sorry for my late reply. >>>> I'm now focusing on the Generator implementation in JSC. >>>> Once it is done, I can work on this :D >>> >>> Thank you! >>> >>> Updated version of patch is here: >>> >>> >>> https://github.com/annulen/webkit/commit/80e914373fc0702708e9fda0cee36ae5ccc22339 >> >> This is very cool. Thank you for doing this. I did something very >> similar in order to build JavaScriptCore for Android. Your changes >> look very similar (but much cleaner). I was hoping those Android >> changes would have been mainlined by now because that was always the >> intent, but the branch got intertwined with a WinRT branch which had >> pretty deep changes and I guess it never got cleaned up. >> >> https://github.com/appcelerator/hyperloop/wiki/Building-JavaScriptCore-for-Android >> >> I’m starting to think that I should try to excavate those changes and >> try to bring them to this Nix branch. > > My plan was to bring this patch to code review after my recent webkitdirs.pm > refactoring gets approved and landed. The most important remaining issue is > naming. I'm currently leaning towards JSCOnly it cmake file names and > --jsc-only flag in build-{webkit,jsc}.
For the time being, here is a current version of patch: https://github.com/annulen/webkit/commits/nix > >> I just tried building this on desktop Linux just to see how things >> work. Here is some random feedback/thoughts: >> >> - libICU is a difficult dependency because it is big and it is not >> guaranteed to be on all systems. (Some context, I’m interested in >> deploying binaries, e.g. SteamOS, Android, so I can’t make users >> install it via package management). So static linking is the preferred >> method. (It’s discussed in the above doc.) Currently, JavaScriptCore >> needs to additionally link against libicudata because the other >> libraries have a dependency on it. Static linking doesn’t pick up on >> the implicit dependency. I don’t think it hurts anything in the >> dynamic library case. >> >> - soname versioning *must* be disabled for Android. I would also like >> an option to shut it off for regular desktop Linux. I am bundling >> JavaScriptCore with my app, so the versioning is mostly a nuisance for >> my build system. > > In general soname is a good thing, but I have no idea about current ABI > stability warranties of JSC. I think it would be better to disable versioning > via build option. > >> - Can somebody explain libllvmForJSC.so? libJavaScriptCore does not >> link to it. Is it actually used? Is it a dlopen type thing? If so, >> since I’m bundling JSCore with my app, what are the rules for where to >> place libllvmForJSC so it can be found/loaded? Is there an C API to >> set the path? >> >> - I think libedit was required for libllvmForJSC.so. libedit is not >> included with SteamOS. I built my own static version and had to set my >> $LIBRARY_PATH environment to make sure it got picked up. This seems >> like it should have gone through the CMake FInd_Library() mechanism so >> I could specify the location directly to the build system. > > If you are not yet ready to experiment with B3, you may want to disable FTL > right away if LLVM dependency causes too much trouble. It may also reduce > memory consumption, but everything depends on your workload, so YMMV. > >> - Windows support for JSC-only would be great. I went through this >> maybe 6 months ago. I submitted feedback/corrections to the people >> trying to document how to build WebKit on Windows. My approach was to >> build everything, but only up through JSCore. So I probably got a ton >> of useless dependencies. And it's a very miserable experience because >> it is so complicated. > > We in Qt port have explored Windows support in build system. Right now we > have to copy bits from PlatformWin.cmake [2, 3], but these things can be > easily shared between all ports targeting Windows. > > We also have some compilation fixes for cases where PLATFORM(WIN) was used > instead of more specific checks [4], we are planning to upstream them soon You may also be interested in this patch: https://bugs.webkit.org/show_bug.cgi?id=143310 > >> - Some general feedback on the gcc 4.9.0 requirement to the WebKit >> team as a whole. This is really hard for SteamOS because it only has >> 4.8.1 (and I don't think I can upgrade without introducing new >> dependencies on glibc/libstdc++ that nobody would have on their >> machines.) I consider myself fortunate that things built under its >> provided clang 3.6. > > I'm also interested in lowering support GCC version to 4.8 because of > vendor-provided toolchain I'm using to target MIPS. Right now JSC builds fine > with GCC 4.8 if you disable FTL. > >> - The size of libJavaScriptCore (and libllvmForJSC) seem to have >> increased quite a bit since the aforementioned Android fork from a >> couple of years ago. I’m now getting around 18MB for each library on >> my desktop build. And this is building ICU with the data archive >> option and not including the actual data archive. I’m a little >> concerned, partly due to Android’s multiple arch situtation and absurd >> APK max size limit (~50MB). > > [1] http://apps.icu-project.org/datacustom/index.html > [2] > https://github.com/annulen/webkit/blob/qtwebkit-1/Source/WTF/wtf/PlatformQt.cmake > [3] > https://github.com/annulen/webkit/blob/qtwebkit-1/Source/JavaScriptCore/PlatformQt.cmake > [4] > https://github.com/annulen/webkit/commit/9c2ba06f21e43ddb653302f124fbb3ed645d1fd9#diff-b019ad41c2b7113a39ca2ef1a03ad41eL52 > > -- > Regards, > Konstantin > _______________________________________________ > webkit-dev mailing list > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-dev -- Regards, Konstantin _______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
