eric at webkit.org
Tue Apr 27 15:51:58 PDT 2010
DerivedSources are generated from here:
I think what your'e thinking of as DerivedSources is actually just the
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:
You can see examples of those scripts being run in DerivedSources.make
or in 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!
On Tue, Apr 27, 2010 at 3:44 PM, Josh Shagam <Joshua.Shagam at am.sony.com> wrote:
> 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
> etc.) rather than the public interface expected by external users of
> 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
> 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 at lists.webkit.org
More information about the webkit-dev