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

[Adam Barth]

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?

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
>