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

[Ami Fischman]

Hajime & I chatted and it became clear that we've been miscommunicating.
I'm taking that conversation off webkit-dev and putting this thread on hold
pending that resolving.  Sorry for the noise.

Cheers,
-a

On Sun, Mar 11, 2012 at 5:54 PM, Hajime Morrita <morrita at chromium.org>wrote:

> I found some confusion here.
>
> There are two kinds of symbols which need to be exported from WebCore.
>
> - A. Symbols from WebCore to WebKit(API). This is basically what
> WebCore.exp.in covers.
> - B. Symbols from WebCore to Application. In principle, there should
> be no such symbols.
>  But in reality there is some. Symbols for Internals objects follow
> this pattern.
>
> Note that the number of B is significantly smaller than one of A.
>
> It looks Alp's main concern is about B. But I implicitly assumed A.
> Currently A matters only for Mac WK1 port (Webcore.exp.in).
> Some other ports including GTK, WebKit2 needs B. (symbols.fiter,
> WebKit_Cairo.def, etc.)
> Mac WK1 also needs B. But it's in the same WebCore.exp.in list.
>
> For A, it should be marked as WEBCORE_EXPORT_PRIVATE if we use inline
> annotations.
> For B, it should use WEBCORE_EXPORT.
>
> For A, I think it's infeasible to replace it with inline annotations
> because the .exp list and inline annotations are mutually exclusive.
> So we need to make it happen at once. But it's not a simple job.
> I think we need some incremental transition plan.
> It might be someting like what Alp mentioned, that is,
> to use nm or whatever to automate exp list generation, etc.
>
> For B, it's relatively easy to turn the macro on because its number is
> small.
> The symbols.filter file shows about 100 symbols, which would be
> manually convertible.
>
> What's tricky is that Chromium component build wants yet another kind
> of symbols: The symbols is for unit testing.
> Let me call it "C" otpion here.
>
> C is different from either A or B. It touches deep WebCore internals
> which people don't need to export unless they write unit tests, that
> is current WebKit situation.
>
> So,
>
> - Some ports need A+B (ex. Mac WK1 Port)
> - Some ports need   B (ex. GTK, Windows)
> - Some ports need   B+C (Chromium)
>  And my feeling is that Chromium is OK to have A if it's available.
>
> ----
>
> 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.
>
> - If WEBCORE_EXPORT and WEBCORE_EXPORT_TEST conflicts, WEBCORE_EXPORT win.
> - If WEBCORE_EXPORT_PRIVATE and WEBCORE_EXPORT_TEST conflicts,
> WEBCORE_EXPORT_TEST win.
> - If WEBCORE_EXPORT and WEBCORE_EXPORT_PRIVATE conflicts (in the
> future), WEBCORE_EXPORT win.
>
> Then we can start from adding C for Chromium, which doesn't have any
> export list before.
> Chromium will also need B. Having B would be good news also for GTK
> and Windows port
> because these no longer need to touch their symbols file for each time
> the Internals object needs one.
> I'm happy to help this to happen. (... and I'd like to ask Ami to help ;-))
>
> What do you think?
>
> --
> morrita
>
> On Mon, Mar 12, 2012 at 9:16 AM, Ami Fischman <fischman at chromium.org>
> wrote:
> > 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.
> >
> > 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/3959c97f/attachment.html>