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 <morr...@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 <fisch...@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 >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev