(From the right address again...)
On Sun, Mar 11, 2012 at 9:34 AM, Alp Toker <a...@nuanti.com> wrote:
> 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, 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, Platform, WebCore, and WebKit, 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 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.
>
This is same for port specific export lists.
To keep the tree green, the community needs to maintain the list
regardless it is externalized from or embedded in the source.
And maintaining the set of export lists has larger pain than
maintaining a macro-based annotation.
Thus keeping it isolated won't help us much.
>, and that the set of imported functions or variables varies between
> ports indicates that this is not going to have wide adoption.
As mrobinson@ mentioned, there is a set of the least common denominator.
My guess is that the number of symbols which is different between
ports will be less than a half of the total.
If we accept such overhead, it could be a preferable option.
>
> 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.
>
At least recent gcc+ld and link.exe support such a class level annotation.
For GNU chain, the lack of support seems like an old story:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9283
My feeling is that the macro annotation is never for declaring a "public API".
It's just a pretty convenient replacement of the port specific export
lists, with small overhead from possible unwanted exports.
It's different from WebKit API which each port is providing.
There is no commitment for compatibility, as the "_PRIVATE" suffix indicates.
To clarify: I think that there should be WEBCORE_EXPORT_PRIVATE but no
WEBCORE_EXORT.
This is unlike JSC, which has both JS_EXPORT and JS_EXPORT_PRIVATE.
(I prefer some shorter name btw... but it's a different topic.)
> 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.
>
So, as I wrote above, this course seems based on a wrong assumption:
The annotation as a public API.
No, it won't. It could be fluid. it would be just an internal tool
which only WebKit port implementations can rely on.
Does this make sense?
--
morrita
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
