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

[Hajime Morrita]

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