Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Eric Wing]

On 2/19/16, Olivier Blin  wrote:
> Le 10/02/2016 17:28, Darin Adler a écrit :
>> That’s going to change over time. We have frequently changed which
>> functions and sections of ICU we use as we develop WebKit. That being
>> said, there is no harm in someone carefully researching exactly what parts
>> of ICU WebKit uses at a particular point in time.
>>
>> Maybe since the two of you both want it, one of you would like to
>> volunteer to do that?
>>
>> I’m not sure there’s anyone else planning on it.
> Hi,
>
> I have similar concerns for building on a set-top box environment, and
> have prepared a patch series to fix build with a light ICU.
> This has been initially done on WebKitForWayland, but it applies to any
> port.
>
> See the following bugs:
> https://bugs.webkit.org/show_bug.cgi?id=154479
> https://bugs.webkit.org/show_bug.cgi?id=154482
> https://bugs.webkit.org/show_bug.cgi?id=154483
> https://bugs.webkit.org/show_bug.cgi?id=154484
>
> With proper stripping, ICU lib/resources can be around 3.5 MB.
>
> Hope this helps
>
> --
> Olivier Blin - SoftAtHome
>
>

Hi, I totally missed this. This looks really useful. Can you explain
the principles/theory behind doing this? Are you doing something to
build a smaller ICU? Or are you some how using post-stripping to
shrink everything? Would you be able to document how to do this?

Thanks,
Eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Olivier Blin]

Le 10/02/2016 17:28, Darin Adler a écrit :

That’s going to change over time. We have frequently changed which functions 
and sections of ICU we use as we develop WebKit. That being said, there is no 
harm in someone carefully researching exactly what parts of ICU WebKit uses at 
a particular point in time.

Maybe since the two of you both want it, one of you would like to volunteer to 
do that?

I’m not sure there’s anyone else planning on it.


(resending to ML)

Hi,

I have similar concerns for building on a set-top box environment, and 
have prepared a patch series to fix build with a light ICU.
This has been initially done on WebKitForWayland, but it applies to any 
port.


See the following bugs:
https://bugs.webkit.org/show_bug.cgi?id=154479
https://bugs.webkit.org/show_bug.cgi?id=154482
https://bugs.webkit.org/show_bug.cgi?id=154483
https://bugs.webkit.org/show_bug.cgi?id=154484

With proper stripping, ICU lib/resources can be around 3.5 MB.

Hope this helps

--
Olivier Blin - SoftAtHome

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Filip Pizło]

> On Feb 10, 2016, at 9:14 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 10.02.2016, 20:10, "Filip Pizło" :
>>>  On Feb 10, 2016, at 1:40 AM, Konstantin Tokarev  wrote:
>>> 
>>>  10.02.2016, 05:41, "Eric Wing" :
>  On 2/7/16, Konstantin Tokarev  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?
>>> 
>>>  It will allow you to disassemble JIT code on architectures that are 
>>> supported by LLVM but lack specialized disassembler inside JSC, e.g. it was 
>>> known to work on ARM traditional.
>> 
>> We should drop the llvm disassembler support since we don't need it for 
>> ARM64, ARMv7, or x86. If we care about disassembly on ARM traditional, we 
>> should write one. It's not that hard.
> 
> Out of curiosity, what is the reason not to reuse LLVM disassemblers? Just 
> because LLVM is "inconvenient" dependency?

It's extremely inconvenient since it doesn't have a stable API. Also in our 
experience that disassembler sometimes only supports those instructions that 
llvm would emit. If you look you'll see that on x86 we choose between the llvm 
disassembler and our own based on whether llvm generated the code or we did, 
since the llvm disassembler has historically had issues handling some of the 
instructions that out MacroAssembler know about. 

There's nothing worse than debugging a jit bug and being blocked on an upstream 
disassembler lacking a feature. It's much better if we have our own. That way 
we won't be blocked. 

> 
> -- 
> Regards,
> Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Konstantin Tokarev]

10.02.2016, 20:10, "Filip Pizło" :
>>  On Feb 10, 2016, at 1:40 AM, Konstantin Tokarev  wrote:
>>
>>  10.02.2016, 05:41, "Eric Wing" :
  On 2/7/16, Konstantin Tokarev  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?
>>
>>  It will allow you to disassemble JIT code on architectures that are 
>> supported by LLVM but lack specialized disassembler inside JSC, e.g. it was 
>> known to work on ARM traditional.
>
> We should drop the llvm disassembler support since we don't need it for 
> ARM64, ARMv7, or x86. If we care about disassembly on ARM traditional, we 
> should write one. It's not that hard.

Out of curiosity, what is the reason not to reuse LLVM disassemblers? Just 
because LLVM is "inconvenient" dependency?

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Filip Pizło]

> On Feb 10, 2016, at 1:40 AM, Konstantin Tokarev  wrote:
> 
> 
> 
> 10.02.2016, 05:41, "Eric Wing" :
>>> On 2/7/16, Konstantin Tokarev  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?
> 
> It will allow you to disassemble JIT code on architectures that are supported 
> by LLVM but lack specialized disassembler inside JSC, e.g. it was known to 
> work on ARM traditional.

We should drop the llvm disassembler support since we don't need it for ARM64, 
ARMv7, or x86. If we care about disassembly on ARM traditional, we should write 
one. It's not that hard. 

> 
>> Also, are there things I can do to shrink JavaScriptCore?

Disable various optimizing JITs if you're desperate enough. 

But I think you could also reduce size by experimenting with out-of-lining cold 
functions that are currently online. That would be a longer term project. 

> 
> 
> You can try to disable all code related to disassembler and inspector (if you 
> don't need these features).
> 
> Also you can try building without API/JSCTestRunnerUtils.cpp and 
> runtime/TestRunnerUtils.cpp.
> 
> 
>> 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 second this request, it would be great if WebKit had a documentation which 
> kinds of ICU data are used by JSC and by WebCore.
> 
> 
>> - 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.
> 
> 
> IIRC, Android is shipped with ICU4J, and in recent ICU versions they are 
> using the same data format.
> 
> 
>> - 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
> 
> -- 
> Regards,
> Konstantin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Darin Adler]

> On Feb 10, 2016, at 1:40 AM, Konstantin Tokarev  wrote:
> 
> 10.02.2016, 05:41, "Eric Wing" :
>> - I don't know what parts JSC actually needs to know what I can safely remove
> 
> I second this request, it would be great if WebKit had a documentation which 
> kinds of ICU data are used by JSC and by WebCore.

That’s going to change over time. We have frequently changed which functions 
and sections of ICU we use as we develop WebKit. That being said, there is no 
harm in someone carefully researching exactly what parts of ICU WebKit uses at 
a particular point in time.

Maybe since the two of you both want it, one of you would like to volunteer to 
do that?

I’m not sure there’s anyone else planning on it.

— Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Konstantin Tokarev]

10.02.2016, 05:41, "Eric Wing" :
> On 2/7/16, Konstantin Tokarev  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

I stronly suggest you to submit patches into bugzilla.

If you never did it before, you can follow steps described here:
https://github.com/annulen/webkit/wiki/How-to-submit-patches-to-webkit.org

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Konstantin Tokarev]

10.02.2016, 05:41, "Eric Wing" :
> On 2/7/16, Konstantin Tokarev  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?

It will allow you to disassemble JIT code on architectures that are supported 
by LLVM but lack specialized disassembler inside JSC, e.g. it was known to work 
on ARM traditional.

> Also, are there things I can do to shrink JavaScriptCore? 


You can try to disable all code related to disassembler and inspector (if you 
don't need these features).

Also you can try building without API/JSCTestRunnerUtils.cpp and 
runtime/TestRunnerUtils.cpp.


> 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 second this request, it would be great if WebKit had a documentation which 
kinds of ICU data are used by JSC and by WebCore.


> - 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.


IIRC, Android is shipped with ICU4J, and in recent ICU versions they are using 
the same data format.


> - 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

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Eric Wing]

On 2/7/16, Konstantin Tokarev  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

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Konstantin Tokarev]

Please try updated version of my branch, it now does not use LLVM unless you 
enable USE_LLVM_DISASSEMBLER.

08.02.2016, 02:18, "Eric Wing" :
> On 2/7/16, Konstantin Tokarev  wrote:
>>  07.02.2016, 14:40, "Eric Wing" :
>>>  I just tried pulling the mainline to try the B3 drop. The merge wasn't so
>>>  clean.
>>>  But right now I'm getting a compile error.
>>>  B3Compilation.cpp.o
>>>
>>>  LLVMHeaders.h:46:10 fatal error: 'llvm-c/Analysis.h' file not found
>>>
>>>  Any ideas?
>>
>>  You have HAVE(LLVM) enabled, but your LLVM installation is not detected or
>>  is broken.
>>  Try to build from scratch or remove CMakeCache.txt (which will trigger full
>>  rebuild)
>
> So this was a build from scratch and I didn't override any defaults
> concerning LLVM (my main thing is -DPORT=Nix) A week ago before the B3
> drop (llvmForJSC), it built and there was no complaint about this
> header.
>
> I didn't do anything to my installation. But I think I may see the
> problem. On my distro, I have the directories,
> /usr/include/llvm-3.4
> /usr/include/llvm-3.6
> /usr/include/llvm-c-3.4
> /usr/include/llvm-c-3.6
>
> I do not have anything without a version number. So
> 'llvm-c/Analysis.h' is not going to find anything.
>
> I suspect the correct solution is to #include "Analysis.h" and
> INCLUDE_DIRECTORIES should specify the correct llvm include directory
> based on the correct find_* logic.
>
> Thanks,
> Eric

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Eric Wing]

On 2/7/16, Konstantin Tokarev  wrote:
>
>
> 07.02.2016, 14:40, "Eric Wing" :
>> I just tried pulling the mainline to try the B3 drop. The merge wasn't so
>> clean.
>> But right now I'm getting a compile error.
>> B3Compilation.cpp.o
>>
>> LLVMHeaders.h:46:10 fatal error: 'llvm-c/Analysis.h' file not found
>>
>> Any ideas?
>
> You have HAVE(LLVM) enabled, but your LLVM installation is not detected or
> is broken.
> Try to build from scratch or remove CMakeCache.txt (which will trigger full
> rebuild)
>

So this was a build from scratch and I didn't override any defaults
concerning LLVM (my main thing is -DPORT=Nix) A week ago before the B3
drop (llvmForJSC), it built and there was no complaint about this
header.

I didn't do anything to my installation. But I think I may see the
problem. On my distro, I have the directories,
/usr/include/llvm-3.4
/usr/include/llvm-3.6
/usr/include/llvm-c-3.4
/usr/include/llvm-c-3.6

I do not have anything without a version number. So
'llvm-c/Analysis.h' is not going to find anything.

I suspect the correct solution is to #include "Analysis.h" and
INCLUDE_DIRECTORIES should specify the correct llvm include directory
based on the correct find_* logic.

Thanks,
Eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Konstantin Tokarev]

07.02.2016, 14:40, "Eric Wing" :
> I just tried pulling the mainline to try the B3 drop. The merge wasn't so 
> clean.
> But right now I'm getting a compile error.
> B3Compilation.cpp.o
>
> LLVMHeaders.h:46:10 fatal error: 'llvm-c/Analysis.h' file not found
>
> Any ideas?

You have HAVE(LLVM) enabled, but your LLVM installation is not detected or is 
broken.
Try to build from scratch or remove CMakeCache.txt (which will trigger full 
rebuild)

>
> Thanks,
> Eric
>
> P.S. Small changes for making SONAME versioning an option and making
> linking work with ICU as a static libraray.
> https://github.com/ewmailing/webkit/commit/ea68782c98cce97c56b44a86008c1a34bc323f6b
> https://github.com/ewmailing/webkit/commit/a6493be74f38b129b7019be9a6c01e9419f7cf74

These patches look good, please submit them to bugzilla.


-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Eric Wing]

I just tried pulling the mainline to try the B3 drop. The merge wasn't so clean.
But right now I'm getting a compile error.
B3Compilation.cpp.o

LLVMHeaders.h:46:10 fatal error: 'llvm-c/Analysis.h' file not found

Any ideas?

Thanks,
Eric

P.S. Small changes for making SONAME versioning an option and making
linking work with ICU as a static libraray.
https://github.com/ewmailing/webkit/commit/ea68782c98cce97c56b44a86008c1a34bc323f6b
https://github.com/ewmailing/webkit/commit/a6493be74f38b129b7019be9a6c01e9419f7cf74
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Carlos Alberto Lopez Perez]

On 01/02/16 00:22, Eric Wing wrote:
>> 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


Due to bug 153638, today I learned that Facebook has also some scripts
for building JSC on Android. I guess you will find it interesting:

https://github.com/facebook/android-jsc
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Konstantin Tokarev]

01.02.2016, 15:21, "Konstantin Tokarev" :
> 01.02.2016, 02:22, "Eric Wing" :
>>  On 1/1/16, Konstantin Tokarev  wrote:
>>>   01.01.2016, 12:46, "Yusuke SUZUKI" :
   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) se

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Konstantin Tokarev]

01.02.2016, 02:22, "Eric Wing" :
> On 1/1/16, Konstantin Tokarev  wrote:
>>  01.01.2016, 12:46, "Yusuke SUZUKI" :
>>>  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}.

>
> 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 

>
> - 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

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Michael Catanzaro]

Hi,

On Sun, 2016-01-31 at 15:22 -0800, Eric Wing wrote:
> - 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.

I don't mind if static linking is an option. (We will keep using
dynamic linking for WebKitGTK+, though, as it's what all our
distributors require.)

> - 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.

Ditto for soname versioning.

> - 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?

Yes, it's a dlopen-type thing. But it's about to go away because we're
about to remove the LLVM dependency (see the recent topics on B3).

See: https://bugs.webkit.org/show_bug.cgi?id=153478

> - 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.

Yes, this is an annoying bug. If it's only needed for libllvmForJSC,
then hopefully the problem is about to go away. :)

> - 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.

Maybe we should lower this requirement.

If you remove the version checks and build with
-DENABLE_DATABASE_PROCESS=OFF -DENABLE_INDEXED_DATABASE=OFF it will
work. See for an example:

https://build.opensuse.org/package/show/GNOME:Next/webkit2gtk3

Actually, it's possible that database process would work with newer
versions of GCC 4.8, but we haven't tested. 4.8.1 is almost certainly
broken, though.

If you're just building JSC, you can safely remove the version checks
(for now).

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Eric Wing]

On 1/1/16, Konstantin Tokarev  wrote:
>
>
> 01.01.2016, 12:46, "Yusuke SUZUKI" :
>> 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

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Konstantin Tokarev]

01.01.2016, 04:26, "Michael Catanzaro" :
> On Thu, 2015-12-31 at 19:25 +0300, Konstantin Tokarev wrote:
>>  Hi Yusuke,
>>
>>  What is the status of this proposal?
>>  AFAICS there were no serious objections, quite the opposite, many
>>  people support your proposal (me too). However, no patches were
>>  landed yet.
>
> I only wonder why it is called Nix? Is it named for http://nixos.org/?
> Or is just supposed to be a generic *nix Unix? Maybe a better name for
> the port would simply be "jsc" or "js"...? It's just when I see "Nix" I
> don't think "JSC only."

I agree, and this port can easily support Windows, invalidating "Nix" name.
However, if we call this port "JSC", build-jsc --jsc will look strange, and
build-webkit --jsc might be misunderstood as "build only JSC part of this
port", i.e. as synonym of build-jsc.

Does anyone have an idea how to name this port?


>
> Did you test this with build-jsc? I guess it's fine to make 'build-
> webkit --nix' do the right thing, but I bet it'd be more convenient to
> just use the build-jsc command.
>
> Michael
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Konstantin Tokarev]

01.01.2016, 12:46, "Yusuke SUZUKI" :
> 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

>
> On Fri, Jan 1, 2016 at 4:02 PM, Konstantin Tokarev  wrote:
>> 01.01.16, 04:26, "Michael Catanzaro" :
>>
>>>On Thu, 2015-12-31 at 19:25 +0300, Konstantin Tokarev wrote:
 Hi Yusuke,

 What is the status of this proposal?
 AFAICS there were no serious objections, quite the opposite, many
 people support your proposal (me too). However, no patches were
 landed yet.
>>>
>>>I only wonder why it is called Nix? Is it named for http://nixos.org/?
>>>Or is just supposed to be a generic *nix Unix?
>>
>> I guess this patch was based on Nix port of WebKit which existed once upon a 
>> time. Yes, it's about *nix, not NixOS
>
> Since Nix port intend to support Unix like (Nix) environment :)
>>> Maybe a better name for
>>>the port would simply be 'jsc' or 'js'...? Its just when I see 'Nix' I
>>>dont think 'JSC only.'
>>>
>>>Did you test this with build-jsc?
>>
>> Yes
>>
>>> I guess its fine to make build-
>>>webkit --nix do the right thing, but I bet itd be more convenient to
>>>just use the build-jsc command.
>>>
>>>Michael
>>>___
>>>webkit-dev mailing list
>>>webkit-dev@lists.webkit.org
>>>https://lists.webkit.org/mailman/listinfo/webkit-dev
>> --
>> -- Regards,
>> Konstantin
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev


-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Yusuke SUZUKI]

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

On Fri, Jan 1, 2016 at 4:02 PM, Konstantin Tokarev 
wrote:

>
>
> 01.01.16, 04:26, "Michael Catanzaro" :
>
> >On Thu, 2015-12-31 at 19:25 +0300, Konstantin Tokarev wrote:
> >> Hi Yusuke,
> >>
> >> What is the status of this proposal?
> >> AFAICS there were no serious objections, quite the opposite, many
> >> people support your proposal (me too). However, no patches were
> >> landed yet.
> >
> >I only wonder why it is called Nix? Is it named for http://nixos.org/?
> >Or is just supposed to be a generic *nix Unix?
>
> I guess this patch was based on Nix port of WebKit which existed once upon
> a time. Yes, it's about *nix, not NixOS
>

Since Nix port intend to support Unix like (Nix) environment :)

>
> > Maybe a better name for
> >the port would simply be 'jsc' or 'js'...? Its just when I see 'Nix' I
> >dont think 'JSC only.'
> >
> >Did you test this with build-jsc?
>
> Yes
>
> > I guess its fine to make build-
> >webkit --nix do the right thing, but I bet itd be more convenient to
> >just use the build-jsc command.
> >
> >Michael
> >___
> >webkit-dev mailing list
> >webkit-dev@lists.webkit.org
> >https://lists.webkit.org/mailman/listinfo/webkit-dev
> --
> -- Regards,
> Konstantin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Konstantin Tokarev]

01.01.16, 04:26, "Michael Catanzaro" :

>On Thu, 2015-12-31 at 19:25 +0300, Konstantin Tokarev wrote:
>> Hi Yusuke,
>> 
>> What is the status of this proposal?
>> AFAICS there were no serious objections, quite the opposite, many
>> people support your proposal (me too). However, no patches were
>> landed yet.
>
>I only wonder why it is called Nix? Is it named for http://nixos.org/?
>Or is just supposed to be a generic *nix Unix?

I guess this patch was based on Nix port of WebKit which existed once upon a 
time. Yes, it's about *nix, not NixOS

> Maybe a better name for
>the port would simply be 'jsc' or 'js'...? Its just when I see 'Nix' I
>dont think 'JSC only.'
>
>Did you test this with build-jsc?

Yes

> I guess its fine to make build-
>webkit --nix do the right thing, but I bet itd be more convenient to
>just use the build-jsc command.
>
>Michael
>___
>webkit-dev mailing list
>webkit-dev@lists.webkit.org
>https://lists.webkit.org/mailman/listinfo/webkit-dev
-- 
-- Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Michael Catanzaro]

On Thu, 2015-12-31 at 19:25 +0300, Konstantin Tokarev wrote:
> Hi Yusuke,
> 
> What is the status of this proposal?
> AFAICS there were no serious objections, quite the opposite, many
> people support your proposal (me too). However, no patches were
> landed yet.

I only wonder why it is called Nix? Is it named for http://nixos.org/?
Or is just supposed to be a generic *nix Unix? Maybe a better name for
the port would simply be "jsc" or "js"...? It's just when I see "Nix" I
don't think "JSC only."

Did you test this with build-jsc? I guess it's fine to make 'build-
webkit --nix' do the right thing, but I bet it'd be more convenient to
just use the build-jsc command.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Konstantin Tokarev]

31.12.2015, 19:25, "Konstantin Tokarev" :
> 11.11.2015, 10:05, "Yusuke SUZUKI" :
>>  Hello WebKittens,
>>
>>  JavaScriptCore use in non-OSX environment looks emerging[1].
>>  In addition to that, sometimes, people would like to build JavaScriptCore 
>> to see what is happning in JavaScriptCore development[2].
>>  However, if you don't have an OSX machine, it is a little bit difficult.
>>  One possible solution is GTK+ port, it is nice way to build JSC in Linux.
>>  But it involves many dependencies (Mesa, glib etc.), that are not necessary 
>> for JavaScriptCore and this is a barrier to join JSC development from non 
>> OSX world.
>>
>>  While building whole WebKit requires many dependencies, JavaScriptCore does 
>> not.
>>  In Nix environment, JavaScriptCore only requires
>>
>>  1. ICU (for WTF unicode libraries and i18n in JSC)
>>  2. LLVM (for FTL!)
>>
>>  That's all. Maintaining the brand new port is tough work.
>>  But maintaining Nix port only for JSC is much much easier since WTF and JSC 
>> are well written for Nix.
>>  In fact, I can build JSC in Nix environment with very small effort, 
>> essentially just adding CMakeLists.txt. Here is my initial attempt[2].
>>
>>  So, the proposal is, how about adding new port NixJSC?
>>  I think it encourages OSS development for JSC.
>>  Unfortunately I cannot attend Fall WebKit MTG, but this could become a nice 
>> topic for the MTG :)
>>
>>  Here is the plan about the NixJSC port.
>>
>>  1. Add new port NixJSC. It provides JavaScriptCore build for Nix 
>> environment. Not provide WebCore, WebKit, WebKit2, etc. It will just build 
>> WTF, bmalloc, and JSC.
>>  2. This port should be suitable for development. So I think aggressively 
>> enabling features is nice for this port; like, enabling FTL!
>>  3. I think this would become a nice playground for OSX guys to enable 
>> features in Nix environment. GTK+ and EFL are somewhat production port. But 
>> NixJSC is intended to be used for development.
>>
>>  If it is introduced, at least, I can support this port.
>>
>>  [1]: 
>> https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/jni/third-party/jsc/Android.mk
>>  [2]: https://twitter.com/BrendanEich/status/652108576836743168
>>  [3]: 
>> https://github.com/Constellation/webkit/commit/a2908e97939ea2881e15ba2d820c377f9bd09297
>>  ,
>
> Hi Yusuke,
>
> What is the status of this proposal?
> AFAICS there were no serious objections, quite the opposite, many people 
> support your proposal (me too). However, no patches were landed yet.

Here is Nix patch updated to current master:

https://github.com/annulen/webkit/commit/2d181790b6945c4255b9df1a7bcf1433f3189ddc

(original Nix port used glib event loop, but I'd like to avoid this dependency, 
that's why I added mock implementations of WorkQueue, MainThread, and RunLoop)


-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Konstantin Tokarev]

11.11.2015, 10:05, "Yusuke SUZUKI" :
> Hello WebKittens,
>
> JavaScriptCore use in non-OSX environment looks emerging[1].
> In addition to that, sometimes, people would like to build JavaScriptCore to 
> see what is happning in JavaScriptCore development[2].
> However, if you don't have an OSX machine, it is a little bit difficult.
> One possible solution is GTK+ port, it is nice way to build JSC in Linux.
> But it involves many dependencies (Mesa, glib etc.), that are not necessary 
> for JavaScriptCore and this is a barrier to join JSC development from non OSX 
> world.
>
> While building whole WebKit requires many dependencies, JavaScriptCore does 
> not.
> In Nix environment, JavaScriptCore only requires
>
> 1. ICU (for WTF unicode libraries and i18n in JSC)
> 2. LLVM (for FTL!)
>
> That's all. Maintaining the brand new port is tough work.
> But maintaining Nix port only for JSC is much much easier since WTF and JSC 
> are well written for Nix.
> In fact, I can build JSC in Nix environment with very small effort, 
> essentially just adding CMakeLists.txt. Here is my initial attempt[2].
>
> So, the proposal is, how about adding new port NixJSC?
> I think it encourages OSS development for JSC.
> Unfortunately I cannot attend Fall WebKit MTG, but this could become a nice 
> topic for the MTG :)
>
> Here is the plan about the NixJSC port.
>
> 1. Add new port NixJSC. It provides JavaScriptCore build for Nix environment. 
> Not provide WebCore, WebKit, WebKit2, etc. It will just build WTF, bmalloc, 
> and JSC.
> 2. This port should be suitable for development. So I think aggressively 
> enabling features is nice for this port; like, enabling FTL!
> 3. I think this would become a nice playground for OSX guys to enable 
> features in Nix environment. GTK+ and EFL are somewhat production port. But 
> NixJSC is intended to be used for development.
>
> If it is introduced, at least, I can support this port.
>
> [1]: 
> https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/jni/third-party/jsc/Android.mk
> [2]: https://twitter.com/BrendanEich/status/652108576836743168
> [3]: 
> https://github.com/Constellation/webkit/commit/a2908e97939ea2881e15ba2d820c377f9bd09297
> ,

Hi Yusuke,

What is the status of this proposal?
AFAICS there were no serious objections, quite the opposite, many people 
support your proposal (me too). However, no patches were landed yet.


-- 
Regards,
Konstantin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[youenn fablet]

On a side note, there used to be https://www.*webkit*
.org/projects/javascript/ 

It seems to be gone after the (nice) revamping of the web site.
Is there (or should there be) some efforts to promote JSC engine there or
somewhere else?

Le mar. 17 nov. 2015 à 00:35, Martin Robinson  a
écrit :

> On Fri, Nov 13, 2015 at 10:15 AM, Osztrogonác Csaba
>  wrote:
> > I like the idea to have a platform free, standalone JSC.
> > It would make easier to maintain various ARM backends.
> >
> > We don't need update-webkit*-libs at all for the
> > standalone JSC, it really depends only on ICU and LLVM.
>
> I think the idea of a standalone JSC is not really incompatible with
> our current setup. javascriptcoregtk doesn't seem to include any GTK+
> specific code, except interaction with the Glib runloop in
> inspector/EventLoop.cpp. Perhaps that could move out of JSC entirely
> or be part of small wrapper library.
>
> --Martin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Martin Robinson]

On Fri, Nov 13, 2015 at 10:15 AM, Osztrogonác Csaba
 wrote:
> I like the idea to have a platform free, standalone JSC.
> It would make easier to maintain various ARM backends.
>
> We don't need update-webkit*-libs at all for the
> standalone JSC, it really depends only on ICU and LLVM.

I think the idea of a standalone JSC is not really incompatible with
our current setup. javascriptcoregtk doesn't seem to include any GTK+
specific code, except interaction with the Glib runloop in
inspector/EventLoop.cpp. Perhaps that could move out of JSC entirely
or be part of small wrapper library.

--Martin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Osztrogonác Csaba]

I like the idea to have a platform free, standalone JSC.
It would make easier to maintain various ARM backends.

We don't need update-webkit*-libs at all for the
standalone JSC, it really depends only on ICU and LLVM.

Ossy

Geoffrey Garen írta:

I think it would be nice to avoid tying the Nix build to update-webkitgtk-libs, 
since part of the stated goal is platform freedom.

Geoff


On Nov 11, 2015, at 2:15 AM, Sergio Villar Senin  wrote:

On 11/11/15 08:04, Yusuke SUZUKI wrote:

Hello WebKittens,

JavaScriptCore use in non-OSX environment looks emerging[1].
In addition to that, sometimes, people would like to build
JavaScriptCore to see what is happning in JavaScriptCore development[2].
However, if you don't have an OSX machine, it is a little bit difficult.
One possible solution is GTK+ port, it is nice way to build JSC in Linux.
But it involves many dependencies (Mesa, glib etc.), that are not
necessary for JavaScriptCore and this is a barrier to join JSC
development from non OSX world.

The gtk port has several external dependencies as any other port and
indeed most of them are not needed for building JSC. However I don't see
those dependencies being a barrier, mainly because we build them using a
jhbuild environment, so even if your distro don't provide the required
dependencies you could build them with Tools/Scripts/update-webkitgtk-libs.

Do you have issues doing that?

BR


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Geoffrey Garen]

I think it would be nice to avoid tying the Nix build to update-webkitgtk-libs, 
since part of the stated goal is platform freedom.

Geoff

> On Nov 11, 2015, at 2:15 AM, Sergio Villar Senin  wrote:
> 
> On 11/11/15 08:04, Yusuke SUZUKI wrote:
>> Hello WebKittens,
>> 
>> JavaScriptCore use in non-OSX environment looks emerging[1].
>> In addition to that, sometimes, people would like to build
>> JavaScriptCore to see what is happning in JavaScriptCore development[2].
>> However, if you don't have an OSX machine, it is a little bit difficult.
>> One possible solution is GTK+ port, it is nice way to build JSC in Linux.
>> But it involves many dependencies (Mesa, glib etc.), that are not
>> necessary for JavaScriptCore and this is a barrier to join JSC
>> development from non OSX world.
> 
> The gtk port has several external dependencies as any other port and
> indeed most of them are not needed for building JSC. However I don't see
> those dependencies being a barrier, mainly because we build them using a
> jhbuild environment, so even if your distro don't provide the required
> dependencies you could build them with Tools/Scripts/update-webkitgtk-libs.
> 
> Do you have issues doing that?
> 
> BR
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Sergio Villar Senin]

On 11/11/15 11:15, Sergio Villar Senin wrote:
> On 11/11/15 08:04, Yusuke SUZUKI wrote:
>> Hello WebKittens,
>>
>> JavaScriptCore use in non-OSX environment looks emerging[1].
>> In addition to that, sometimes, people would like to build
>> JavaScriptCore to see what is happning in JavaScriptCore development[2].
>> However, if you don't have an OSX machine, it is a little bit difficult.
>> One possible solution is GTK+ port, it is nice way to build JSC in Linux.
>> But it involves many dependencies (Mesa, glib etc.), that are not
>> necessary for JavaScriptCore and this is a barrier to join JSC
>> development from non OSX world.
> 
> The gtk port has several external dependencies as any other port and
> indeed most of them are not needed for building JSC. However I don't see
> those dependencies being a barrier, mainly because we build them using a
> jhbuild environment, so even if your distro don't provide the required
> dependencies you could build them with Tools/Scripts/update-webkitgtk-libs.

BTW, as KaL points out on irc, we could teach our build scripts to not
build all the dependencies when building JSC only. I shouldn't be
difficult to create a update-jsc-libs as I think glib should be the only
dependency of WTF and JSC.

BR
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Sergio Villar Senin]

On 11/11/15 08:04, Yusuke SUZUKI wrote:
> Hello WebKittens,
> 
> JavaScriptCore use in non-OSX environment looks emerging[1].
> In addition to that, sometimes, people would like to build
> JavaScriptCore to see what is happning in JavaScriptCore development[2].
> However, if you don't have an OSX machine, it is a little bit difficult.
> One possible solution is GTK+ port, it is nice way to build JSC in Linux.
> But it involves many dependencies (Mesa, glib etc.), that are not
> necessary for JavaScriptCore and this is a barrier to join JSC
> development from non OSX world.

The gtk port has several external dependencies as any other port and
indeed most of them are not needed for building JSC. However I don't see
those dependencies being a barrier, mainly because we build them using a
jhbuild environment, so even if your distro don't provide the required
dependencies you could build them with Tools/Scripts/update-webkitgtk-libs.

Do you have issues doing that?

BR
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Thought about Nix JavaScriptCore port

[Filip Pizlo]

I like this idea. It makes sense to simplify building JSC as a standalone on 
Linux. 

-Filip

> On Nov 10, 2015, at 11:04 PM, Yusuke SUZUKI  wrote:
> 
> Hello WebKittens,
> 
> JavaScriptCore use in non-OSX environment looks emerging[1].
> In addition to that, sometimes, people would like to build JavaScriptCore to 
> see what is happning in JavaScriptCore development[2].
> However, if you don't have an OSX machine, it is a little bit difficult.
> One possible solution is GTK+ port, it is nice way to build JSC in Linux.
> But it involves many dependencies (Mesa, glib etc.), that are not necessary 
> for JavaScriptCore and this is a barrier to join JSC development from non OSX 
> world.
> 
> While building whole WebKit requires many dependencies, JavaScriptCore does 
> not.
> In Nix environment, JavaScriptCore only requires
> 
> 1. ICU (for WTF unicode libraries and i18n in JSC)
> 2. LLVM (for FTL!)
> 
> That's all. Maintaining the brand new port is tough work.
> But maintaining Nix port only for JSC is much much easier since WTF and JSC 
> are well written for Nix.
> In fact, I can build JSC in Nix environment with very small effort, 
> essentially just adding CMakeLists.txt. Here is my initial attempt[2].
> 
> So, the proposal is, how about adding new port NixJSC?
> I think it encourages OSS development for JSC.
> Unfortunately I cannot attend Fall WebKit MTG, but this could become a nice 
> topic for the MTG :)
> 
> Here is the plan about the NixJSC port.
> 
> 1. Add new port NixJSC. It provides JavaScriptCore build for Nix environment. 
> Not provide WebCore, WebKit, WebKit2, etc. It will just build WTF, bmalloc, 
> and JSC.
> 2. This port should be suitable for development. So I think aggressively 
> enabling features is nice for this port; like, enabling FTL!
> 3. I think this would become a nice playground for OSX guys to enable 
> features in Nix environment. GTK+ and EFL are somewhat production port. But 
> NixJSC is intended to be used for development.
> 
> If it is introduced, at least, I can support this port.
> 
> [1]: 
> https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/jni/third-party/jsc/Android.mk
> [2]: https://twitter.com/BrendanEich/status/652108576836743168
> [3]: 
> https://github.com/Constellation/webkit/commit/a2908e97939ea2881e15ba2d820c377f9bd09297
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Thought about Nix JavaScriptCore port

[Yusuke SUZUKI]

Hello WebKittens,

JavaScriptCore use in non-OSX environment looks emerging[1].
In addition to that, sometimes, people would like to build JavaScriptCore
to see what is happning in JavaScriptCore development[2].
However, if you don't have an OSX machine, it is a little bit difficult.
One possible solution is GTK+ port, it is nice way to build JSC in Linux.
But it involves many dependencies (Mesa, glib etc.), that are not necessary
for JavaScriptCore and this is a barrier to join JSC development from non
OSX world.

While building whole WebKit requires many dependencies, JavaScriptCore does
not.
In Nix environment, JavaScriptCore only requires

1. ICU (for WTF unicode libraries and i18n in JSC)
2. LLVM (for FTL!)

That's all. Maintaining the brand new port is tough work.
But maintaining Nix port only for JSC is much much easier since WTF and JSC
are well written for Nix.
In fact, I can build JSC in Nix environment with very small effort,
essentially just adding CMakeLists.txt. Here is my initial attempt[2].

So, the proposal is, how about adding new port NixJSC?
I think it encourages OSS development for JSC.
Unfortunately I cannot attend Fall WebKit MTG, but this could become a nice
topic for the MTG :)

Here is the plan about the NixJSC port.

1. Add new port NixJSC. It provides JavaScriptCore build for Nix
environment. Not provide WebCore, WebKit, WebKit2, etc. It will just build
WTF, bmalloc, and JSC.
2. This port should be suitable for development. So I think aggressively
enabling features is nice for this port; like, enabling FTL!
3. I think this would become a nice playground for OSX guys to enable
features in Nix environment. GTK+ and EFL are somewhat production port. But
NixJSC is intended to be used for development.

If it is introduced, at least, I can support this port.

[1]:
https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/jni/third-party/jsc/Android.mk
[2]: https://twitter.com/BrendanEich/status/652108576836743168
[3]:
https://github.com/Constellation/webkit/commit/a2908e97939ea2881e15ba2d820c377f9bd09297
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev