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

[Ami Fischman]

Responding to several emails below.

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).
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.

Adam also wrote:

> 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?


The latter.  To put things in perspective, WebCore.exp.in is over 2000
lines long; my patch macro-annotates ~40 classes in WebCore (which is a far
cry from, say, doubling the pain of WebCore.exp.in).
I'm also emboldened in this respect by the coexistence of WEBKIT_EXPORT and
Source/WebKit/mac/WebKit.exp<http://code.google.com/p/chromium/source/search?q=file%3AWebKit%2FSource%2FWebKit%2Fmac%2FWebKit.exp&origq=file%3AWebKit%2FSource%2FWebKit%2Fmac%2FWebKit.exp&btnG=Search+Trunk>
.

Alp wrote:

> Doesn't the list of exports change massively based on the level of
> inlining and compiler optimisation? Which configuration is the target to
> aim for, and which compiler vendor?

Doesn't the list also change between releases of the same compiler?
>

AFAICT the answers to your questions are all "no", for the limited scope of
my change (some indication of this is that I only tested my patch on
chromium/linux, but it's now green on all EWS bots after only needing to
add #include's to get the definition of the export macro, not due to having
to add extra annotations for some ports).
As with the existing JSC_EXPORT and WEBKIT_EXPORT macros, the new
WEBCORE_EXPORT_PRIVATE (nee (unused) WEBKIT_EXPORTDATA) will be an
annotation added by whoever lands a patch that requires access to something
from outside the library that today doesn't require it.

Ash proposed replacing both the explicit post-mangled export lists and
in-line macros with per-port export-lists that would be used at build time
to emit modified headers.  I'd have to see a PoC of this to believe that it
wouldn't combine the worst aspects of all the options on the table ;)  The
proposal assumes a lot of things I don't believe are *strictly* true, and I
believe the gap between "almost right" and "strictly right" is where enough
pain will come from to sink this option.

Cheers,
-a
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120311/ea0806ab/attachment.html>