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