Thanks. I apologize for mincing terminology - I'm not particularly
versed in how WebKit is put together, where WebKit ends and
JavaScriptCore begins, etc., and I've mostly been banging my head
against this based on looking at work that some of my coworkers have
done. :)
I should be more specific that we are in fact linking against WebKit and
so we will have the implementations available. We are actually using
full WebKit for another part of the system as well, but we'd like to be
able to access WebKit's JS bindings from outside of the WebKit view.
It looks like bindings/scripts bit will help me get on the right track,
in any case. Thanks for the pointer.
Eric Seidel wrote:
DerivedSources are generated from here:
http://trac.webkit.org/browser/trunk/WebCore/DerivedSources.make
I think what your'e thinking of as DerivedSources is actually just the
javascript bindings, which will be useless to you w/o the actual
implementations in WebCore.
If for some reason you wanted to write your own custom bindings which
use JSC's public API instead of the internal one which WebCore uses,
you could make your own generator script:
http://trac.webkit.org/browser/trunk/WebCore/bindings/scripts/
You can see examples of those scripts being run in DerivedSources.make
or in run-bindings-tests:
http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/run-bindings-tests
In short, this is not a supported configuration. :) I'm also not
really sure it's on topic for this list.
Best of luck!
-eric
On Tue, Apr 27, 2010 at 3:44 PM, Josh Shagam <joshua.sha...@am.sony.com> wrote:
Hi, I'm working on a project which makes use of JavaScriptCore as a
scripting engine outside of WebKit. It would be very helpful to us if we
could get access to the DOMParser and XMLSerializer classes which are in
WebKit's DerivedSources area. However, it seems that those libraries are
using JavaScript Core's internal/private API (JSC::ExecState, JSC::Value,
etc.) rather than the public interface expected by external users of
JavaScript Core.
We'd also like to avoid pulling in the internal WebKit headers anyway, as
this would complicate our build system (for example, we'd like to be able to
do this just using the header files provided by Ubuntu's libwebkit-dev
package). I'm fine with writing forward-declaration classes and stub
methods for the purpose of letting the C++ linker figure it all out, but
JSC::JSValue seems to get in the way of this idea, since the
getConstructor() methods on the libraries we want return it by value rather
than by reference (and it doesn't appear to be a simple reinterpret_cast
like it is for the other public-API classes).
Is there some official way that we can get at WebKit's DerivedSources
library functionality in a non-WebKit JavaScript Core application, or can
anyone think of some tricky-but-relatively-clean way to do it that doesn't
involve our app having to see JSC's internal API?
Thanks in advance.
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
