[webkit-dev] exporting symbols for building .so/.dll's

[Ami Fischman]

Thanks for your reply, Morrita!


> For ports on approach "C", it doesn't matter which WebCore/JSC API is

 used from WebKit API layer because they are built in the same library.
>

If you mean that nothing in WebCore/JSC needs to be annotated as exported
then I don't think that's right, because libwebkit.so has various other
libwebcore_*.a's linked into it.
E.g. if I revert the change I made to
JavaScriptCore/wtf/chromium/ChromiumThreading.h to *not*
have ChromiumThreading be declared WTF_EXPORT, then the link of
webkit_unit_tests fails because libwtf.a
(JavaScriptCore/wtf/chromium/MainThreadChromium.cpp) contains a call to
WTF::ChromiumThreading::callOnMainThread which is a hidden symbol in
libwebkit.so (WebKit/chromium/src/ChromiumThreading.cpp).
Maybe I misunderstood your point?

For JSC API, which "A" and "B" folks care about, there are two ways to
> export it.
> - For Windows port, there is JavaScriptCore.def.
> - For Mac (and WX?) port, there are macro-based annotations like
> JS_EXPORT, WTF_EXPORT_PRIVATE.
> I'm in the way to eliminate JavaScriptCore.def by replacing it with these
> annotations, but the migration isn't finished yet. (http://wkb.ug/76257)
>

Yay.


> For WebCore API, we only need to care about WebCore.exp.in because Mac
> port is the only one which follows "A" pattern. (I remember Windows
> port used to use this pattern. But it looks no longer the case. Maybe
> they changed the way when they switched to WebKit2. But my memory
> might be just wrong...)
>

I'm curious whether you have plans (or know of others' plans) to replace
WebCore.exp.in in favor of macros, like you did in http://webk.it/72854 for
JavaScriptCore.exp.

My personal preference is to introduce WebCore version of export
> macros like WK_EXPORT_PRIVATE. In this way, we could use it to get rid
> of WebCore.exp.in in the future.
>

Isn't that what
WEBKIT_EXPORTDATA<http://cs/#chrome/src/third_party/WebKit/Source/WebCore/platform/PlatformExportMacros.h&q=file:WebCore/platform/PlatformExportMacros.h%20WEBKIT_EXPORTDATA&l=39>
already
is?  (contrary to the macro's name, it lives in WebCore; perhaps it is
trickier than I realize and somehow only applies to WebKit code even though
it lives in WebCore?  Or maybe it just needs to be renamed?)

Yet another approach could be just giving up to have the unit test as a
> separate binary and build it into the library for non-prod
> configuration. The last one seems exactly what you are trying to avoid
> though...


Right; linking test code into the main library is what HEAD does now.


> Anyway, I'd like to hear thoughts from other folks.
>

Me too.  As someone pointed out to me, others might be too busy with the
git thread to  reply to this one :)

Cheers,
-a
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120309/14605c25/attachment.html>