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

[Hajime Morrita]

(From the right address...)

Hi Ami,

I don't think there is a consensus about that. Here is my
understanding of the current status of the export symbol management:

At first, each port has different way to split libraries. For example,

- A) Mac port (WebKit1) splits WebKit into three frameworks: WebCore,
JavaScriptCore and WebKit.
 (The last one is for Objective-C API which wraps WebCore.)
- B) Some others split it into JavaScriptCore and WebCore+WebKit.
- C) Chromium chooses yet another variation: making a single library
for whole WebKit.

This difference is one of the reasons why the way to export symbols is
different among ports.

For ports on approach "C", it doesn't matter which WebCore/JSC API is
used from WebKit API layer because they are built in the same library.
For ports on approach "B", only the symbols exported from JSC matter.
The dependency from WebKit API to WebCore doesn't.
For ports on approach "A", symbols exported both from JSC and WebCore
matter because these two have their own libraries. APIs of these
libraries should be exported to be used by WebKit API library.

Also, there are port specific WebKit APIs (like WebFrame and WebString
of Chromium.) which have their own ways to export symbols. But in
general, people other than the port maintainers don't need to care
about that because there are few chances to change such APIs.

---

I'd try to clarify some more detail:

For JSC API, which "A" and "B" folks care about, there are two ways to
export it.

- For Windows port, there is JavaScriptCore.def.
- For Mac (and WX?) port, there are macro-based annotations like
JS_EXPORT, WTF_EXPORT_PRIVATE.

I'm in the way to eliminate JavaScriptCore.def by replacing it with
these annotations, but the migration isn't finished yet.
(http://wkb.ug/76257)

For WebCore API, we only need to care about WebCore.exp.in because Mac
port is the only one which follows "A" pattern. (I remember Windows
port used to use this pattern. But it looks no longer the case. Maybe
they changed the way when they switched to WebKit2. But my memory
might be just wrong...)

---

Having that long said, back to the original question:

> Is there consensus on the list for what the Right Thing To Do(tm) is?
> ISTM my options are:
> 1) Add EXPORT declarations as in the patch on the bug.
> 2) Drop the patch from the bug and replace it with chromium-specific
> .exp.in-style files, one per layer from which I need to export (WebCore,
> WTF, WebKit).  And build the build-time machinery to use them.  I don't
> really know what's involved here and would appreciate any pointers/hints
> people had if this is the way to go.
> 3) Something else (preferably unifying other ports' approaches).

- If the API is under JavaScriptCore/ (or WTF/), I'd recommend to use
JS_EXPORT and WTF_EXPORT_PRIVATE because we are under transition to
this path.
- If the API is under WebKit/chromium/, we can just use WEBKIT_EXPORT as before.
- If the API is under WebCore/, there is no consensus except we
already have WebCore.exp.in.

My personal preference is to introduce WebCore version of export
macros like WK_EXPORT_PRIVATE. In this way, we could use it to get rid
of WebCore.exp.in in the future.

Another possibility is to ride existing WebCore.exp.in somehow. Yet
another approach could be just giving up to have the unit test as a
separate binary and build it into the library for non-prod
configuration. The last one seems exactly what you are trying to avoid
though... One clear thing is that maintaining yet another exp file
will be bad news for almost everyone ;-)

Anyway, I'd like to hear thoughts from other folks.

Bests,
--
morrita

> _______________________________________________
> webkit-dev mailing list

On Fri, Mar 9, 2012 at 12:52 PM, Ami Fischman <fischman at chromium.org> wrote:
> Hi webkittens,
>
> The over-all question: how should webkit libraries declare which symbols
> they export?
> The trigger for the question: as described in bug 80062, the chromium
> shared-library-based build links test code into the (non-test) libwebkit.so
> target, which is terrible.
>
> The details:
> I took a crack at fixing the above bug (see patch in the bug) by pulling the
> test files out of the non-test build target, and sprinkling various
> {WTF,WEBKIT}_EXPORT{,DATA} macros around declarations that need them (as
> discovered by build-time and run-time failures).  This style of export
> declaration is what the webkit codebase does in various places
> (WTF, Platform, WebCore, and WebKit, AFAICT), and incidentally also what
> the chromium project uses for its sub-components.
> But I'm told other ports use different mechanisms such as .exp.in files for
> apple/mac (and maybe others for other ports? IDK).
>
> Is there consensus on the list for what the Right Thing To Do(tm) is?
> ISTM my options are:
> 1) Add EXPORT declarations as in the patch on the bug.
> 2) Drop the patch from the bug and replace it with chromium-specific
> .exp.in-style files, one per layer from which I need to export (WebCore,
> WTF, WebKit).  And build the build-time machinery to use them.  I don't
> really know what's involved here and would appreciate any pointers/hints
> people had if this is the way to go.
> 3) Something else (preferably unifying other ports' approaches).
>
> Help me webkit-dev, you're my only hope (for consensus).
>
> Cheers,
> -a
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>