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

Sun Mar 11 11:15:02 PDT 2012

On Sun, Mar 11, 2012 at 11:13 AM, Adam Barth <abarth at webkit.org> wrote:
> On Sun, Mar 11, 2012 at 10:49 AM, Ami Fischman <fischman at chromium.org> wrote:
>> 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.
>
> I'm not sure I understand your proposal fully.  Specifically, how
> would these macros work for, say, the Chromium, Apple-Mac, and
> Apple-Win ports, which export overlapping, but not identical, sets of
> symbols?

Relatedly, do you plan to replace
<http://trac.webkit.org/browser/trunk/Source/WebCore/WebCore.exp.in>
with EXPORT macros, or will we have both macros and an export list for
an extended period of time?

Adam

>> 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.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 at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>