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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
