We should split JSC and WebKit/WebCore builds so that JSC can be used as a separate lib outside of WebKit.
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.
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
Ping?
Created attachment 91424 [details] Patch
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.
Created attachment 91505 [details] pkgconfig.diff This adds a pkg-config file for the new library.
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.
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?
(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.
This landed: http://trac.webkit.org/changeset/85225 http://trac.webkit.org/changeset/85224