[webkit-dev] Thought about Nix JavaScriptCore port

[Konstantin Tokarev]

01.02.2016, 15:21, "Konstantin Tokarev" <annulen at yandex.ru>:
> 01.02.2016, 02:22, "Eric Wing" <ewmailing at gmail.com>:
>>  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.
>
> 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
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin