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

[Ami Fischman]

I'm inclined to give this thread one more business day and then call it
Tuesday morning pacific time.
On current showing I think the approach in the patch on the bug (incl.
morrita@'s preference for WEBCORE_EXPORT_PRIVATE) is the way to go, at
least for now.
If you have strong concerns please speak up before then.

Cheers,
-a

On Sun, Mar 11, 2012 at 3:02 AM, Hajime Morrita <morrita at chromium.org>wrote:

> (From the right address again...)
>
> On Sun, Mar 11, 2012 at 9:34 AM, Alp Toker <alp at 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.infiles 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120311/3c421558/attachment.html>