Bug 19428 – [Gtk] Split JSC and WebCore builds

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Jan Alonzo]

We should split JSC and WebKit/WebCore builds so that JSC can be used as a separate lib outside of WebKit.

[Alp Toker]

Agreed. We'll need to figure out how to export the JSCore internals used by WebCore, since everything but the C public API is currently hidden.

We might be able to do this by:

1) Making everything in JSCore exported and public (not great, but guaranteed to work)

2) Using the defs file used by Apple (could be problematic since our builds are different to theirs, and the C++ mangling may be different in the compilers/compiler versions we support)

3) Convincing libtool or something else in the build system to generate a defs file at build time.

4) Maintaining our own defs files (has some of the same issues as (2) and is a pain for us to maintain.

I expect (1) or (3) to be easiest to implement. Need to experiment and see what works.

[Jan Alonzo]

Alp, here's my plan:

* Have a separate JSC build extracted from what we already have now. The JSC build can be standalone as well as invokable by the top-level WebKit autogen.sh/configure.

* The JSC build will result in a libjavascriptcore library, installable with a separate pkg-config file. My issue here right now is versioning. Should we call it 3.1 to match what's in WebKitAvailability?

I just started and just want to ask you if the points above are fine with you.

cheers

[Gustavo Noronha (kov)]

Ping?

[Estêvão Samuel Procópio Amaral]

Ping?

[Xan Lopez]

Created attachment 91424 [details]
Patch

[Xan Lopez]

Still WIP would be the visibility issues (right now everything is public by default, since we need WebKit to find some symbols in JSC) and the pkg-config file, which will come in another patch.

[Xan Lopez]

Created attachment 91505 [details]
pkgconfig.diff

This adds a pkg-config file for the new library.

[Martin Robinson]

Comment on attachment 91505 [details]
pkgconfig.diff

View in context: https://bugs.webkit.org/attachment.cgi?id=91505&action=review

> Source/WebKit/gtk/GNUmakefile.am:584
>  	$(top_builddir)/Source/WebKit/gtk/@WEBKITGTK_PC_NAME@-@WEBKITGTK_API_VERSION@.pc \
> +	$(top_builddir)/Source/WebKit/gtk/javascriptcoregtk-@WEBKITGTK_API_VERSION@.pc
>  	$(top_builddir)/Source/WebKit/gtk/org.webkitgtk-@WEBKITGTK_API_VERSION@.gschema.xml \

Pretty sure you're missing a \ at the end of this line.

[Martin Robinson]

Comment on attachment 91424 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=91424&action=review

> GNUmakefile.am:-130
> -# Convenience libraries
> -noinst_LTLIBRARIES += \
> -	libJavaScriptCore.la
> -
> -nodist_EXTRA_libJavaScriptCore_la_SOURCES = \

I'm really happy to see this stuff move out of the main GNUmakefile.am finally!

> Source/JavaScriptCore/GNUmakefile.am:36
> +libjavascriptcoregtk_@WEBKITGTK_API_MAJOR_VERSION@_@WEBKITGTK_API_MINOR_VERSION@_la_CFLAGS = \
> +	-fstrict-aliasing \
> +	-O3 \

Seems like the optimization level should be global across all libraries. That is unrelated to this patch though.

> Source/JavaScriptCore/GNUmakefile.am:112
> +	$(AM_V_GEN)cp -f Programs/jsc-@WEBKITGTK_API_MAJOR_VERSION@$(EXEEXT) Programs/jsc$(EXEEXT)

A symlink might be better here?

[Xan Lopez]

(In reply to comment #9)
+libjavascriptcoregtk_@WEBKITGTK_API_MAJOR_VERSION@_@WEBKITGTK_API_MINOR_VERSION@_la_CFLAGS = \
> > +	-fstrict-aliasing \
> > +	-O3 \

This bothers me too!

> 
> Seems like the optimization level should be global across all libraries. That is unrelated to this patch though.
> 
> > Source/JavaScriptCore/GNUmakefile.am:112
> > +	$(AM_V_GEN)cp -f Programs/jsc-@WEBKITGTK_API_MAJOR_VERSION@$(EXEEXT) Programs/jsc$(EXEEXT)
> 
> A symlink might be better here?

I think I tried that in the past and had some problems, but we can try again. In any case it was already there too, so we can fix it later.

[Martin Robinson]

This landed:

http://trac.webkit.org/changeset/85225
http://trac.webkit.org/changeset/85224