On 1/1/16, Konstantin Tokarev <annu...@yandex.ru> wrote: > > > 01.01.2016, 12:46, "Yusuke SUZUKI" <utatane....@gmail.com>: >> 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. 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. - 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. - 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. - 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. - 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). _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
