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

[Adam Barth]

On Sun, Mar 11, 2012 at 5:16 PM, Ami Fischman <fischman at chromium.org> wrote:
> Adam wrote:
>> 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?
>
> I do not have a proposal to unify the export story across ports.  My
> "proposal" (such as it is) is limited to removing test code from the
> non-test webkit target (see the patch on the bug).

It's important to consider how these approaches work for ports besides
Chromium.  WebCore is used by many folks besides just Chromium.

> AFAICT from this thread there is no consensus on unifying options that
> doesn't have as its first step "achieve consensus on the complete public API
> of each library layer", and I didn't get the sense that this is a realistic
> goal, at least for me at my current level of engagement.

WebCore has no public API, so that part is easy to reach consensus about.  :)

On Sun, Mar 11, 2012 at 5:54 PM, Hajime Morrita <morrita at chromium.org> wrote:
> Having that said, here is my proposal:
>
> - Let's introduce WEBCORE_EXPORT for B.
>  Chromium will use this, GTK and Windows also could use. (For GTK, I
> expect this to have same definition as WEBKIT_API.)
>
> - Let's NOT introduce WEBCORE_EXPORT_PRIVATE for now
>  because it would be useless unless we don't get rid of
> WebCore.exp.in, which won't easy.
>
> - Let's introduce WEBCORE_EXPORT_TEST for C.
>  Chromium will enable and use this for now.
>
> [...]
>
> What do you think?

This approach sounds promising because the symbols needed for
Internals and for unit testing are likely to be quite similar across
ports (as opposed to, for example, the WebCore symbols needed by the
various different WebKit layers).  That means that the symbols
annotated with WEBCORE_EXPORT and WEBCORE_EXPORT_TEST are likely to be
exported by many ports.

Adam