[webkit-dev] exporting symbols for building .so/.dll's
fischman at chromium.org
Sun Mar 11 19:30:57 PDT 2012
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.
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
> 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
> 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.
> - 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?
> On Mon, Mar 12, 2012 at 9:16 AM, Ami Fischman <fischman at chromium.org>
> > 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
> >> 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
> > of each library layer", and I didn't get the sense that this is a
> > 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
> > 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
> > 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
> > #include's to get the definition of the export macro, not due to having
> > 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
> > 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
> > to emit modified headers. I'd have to see a PoC of this to believe that
> > wouldn't combine the worst aspects of all the options on the table ;)
> > 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
> > pain will come from to sink this option.
> > Cheers,
> > -a
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev