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

[Alp Toker]

On 09/03/2012 03:52, Ami Fischman wrote:
> Hi webkittens,
>
> The over-all question: how should webkit libraries declare which 
> symbols they export?
> The trigger for the question: as described in bug 80062 
> <https://bugs.webkit.org/show_bug.cgi?id=80062>, the chromium 
> shared-library-based build links test code into the (non-test) 
> libwebkit.so target, which is terrible.
>
> The details:
> I took a crack at fixing the above bug (see patch in the bug) by 
> pulling the test files out of the non-test build target, and 
> sprinkling various {WTF,WEBKIT}_EXPORT{,DATA} macros around 
> declarations that need them (as discovered by build-time and run-time 
> failures).  This style of export declaration is what the webkit 
> codebase does in various places (WTF 
> <http://code.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/JavaScriptCore/wtf/ExportMacros.h&exact_package=chromium&q=WTF_EXPORT&type=cs&l=39>, 
> Platform 
> <http://code.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/Platform/chromium/public/WebCommon.h&exact_package=chromium&q=WEBKIT_EXPORT&l=68>, 
> WebCore 
> <http://code.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/platform/PlatformExportMacros.h&exact_package=chromium&q=define%5C%20WEBKIT_EXPORT&ct=rc&cd=2&sq=&l=39>, 
> and WebKit 
> <http://code.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebKit/chromium/public/platform/WebCommon.h&exact_package=chromium&q=file:%28%5E%7C/%29platform/WebCommon%5C.h$>, 
> AFAICT), and incidentally also what the chromium project uses for its 
> sub-components.
> But I'm told other ports use different mechanisms such as .exp.in 
> files 
> <http://code.google.com/p/chromium/source/search?q=file%3ASource%2FWebCore%2FWebCore.exp.in&origq=file%3ASource%2FWebCore%2FWebCore.exp.in&btnG=Search+Trunk> for 
> apple/mac (and maybe others for other ports? IDK).
>
> Is there consensus on the list for what the Right Thing To Do(tm) is?
> ISTM my options are:
> 1) Add EXPORT declarations as in the patch on the bug.
> 2) Drop the patch from the bug and replace it with chromium-specific 
> .exp.in-style files, one per layer from which I need to export 
> (WebCore, WTF, WebKit).  And build the build-time machinery to use 
> them.  I don't really know what's involved here and would appreciate 
> any pointers/hints people had if this is the way to go.
> 3) Something else (preferably unifying other ports' approaches).
>
> Help me webkit-dev, you're my only hope (for consensus).
>

I think the export macros would only ever have made sense if they were 
put there explicitly to guide refactoring of the classes into a library 
/ interface structure. And this isn't the case.

At present I don't see an active effort towards that, or much interest 
in defining the public interfaces in each 'module' more strictly. 
They're intentionally fluid.

Having said that, the macros are /vaguely/ useful to see what could be 
made private or hidden in future shuffling of the code in wtf, for 
example, but that's about it.

The very fact that the export macros have to be updated with a tool 
every time a library higher in the link chain uses or doesn't use a 
public entry point, and that the set of imported functions or variables 
varies between ports indicates that this is not going to have wide adoption.

If we follow this to the logical conclusion, no unification of granular 
export lists is realistic with the current WebKit porting layer. If the 
strategy were adapted to define exported functionality at class 
granularity, it might just be feasible, but again that is a contract 
that is begging to be broken, and besides, most toolchains lack 
export-by-class so it's a moot point.

So the ultimate course of action is then to revert the macros and leave 
everyone to do what they think best in terms of export lists, then tying 
together those solutions where there's overlap.

The exception is, of course, clearly defined public API (of which there 
is not much), such as this case where we added JS_EXPORT to the 
JavaScriptCore API for the benefit of multiple ports and also consumers: 
http://trac.webkit.org/changeset/28097

(In a port I worked on in the past we developed a vendor tool to detect 
inter-dependencies at compile time so there were no lists to update, but 
again, this would not be portable.)

Spoken with my devil's advocate hat on, would be great if you can prove 
me wrong.

-- 
http://www.nuanti.com
the browser experts

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120311/8f68fa4b/attachment.html>