[webkit-dev] Thought about Nix JavaScriptCore port

[Eric Wing]

On 1/1/16, Konstantin Tokarev <annulen at yandex.ru> wrote:
>
>
> 01.01.2016, 12:46, "Yusuke SUZUKI" <utatane.tea at 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).