[webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))

[Hajime Morrita]

The history aside, I think it makes sense to use the export macro
specifically for Mac WebCore because

- As Eric mentioned, Currently only Mac and Win WebCore do WebCore/WebKit
separation.
  Other ports like GTK or Chromium build single "WebKit" library which has
both WebCore and WebKit API included.
  So we need to care about only Mac and Win for now.

- Mac WebKit has relatively comprehensive feature set. It covers most of
possibly exported symbols.

- The Windows toolchain allows us to use both export symbols list and
source-level annotation (the macro).
  Thus on Windows, we could use the Mac-centered export macro *and* an
export symbol list which covers Win-specific exports.

  This means that there are unused exports on Win build, but I believe it
is very few considering that Mac/Win ports has
  similar feature set, which targets Safari on each platform. (This might
be wrong assumption though - On Mac, there are
  many other WebKit embedder other than Safari.)

One exception is symbols exported for WebCoreTesting.
Fortunately, these symbols are exactly same across ports and we can use
another macro like
WEBCORE_TESTING_EXPORT for that.

--
morrita

On Fri, Feb 1, 2013 at 9:14 AM, Eric Seidel <eric at webkit.org> wrote:

> I believe that it's a design mistake for WebCore to need to know
> anything about it's embedder, more than that there is a defined set of
> platform APIs and callbacks which it talks to (which should be the
> exact same for every embedder).
>
> (The export dependency dates back to the WebCore/WebKit separation,
> which in my recollection was done largely to be able to isolate LGPL
> code from the non-LGPL Mac WebKit layer.)
>
> But I believe it is a mistake that WebCore changes need to care about
> the possibility that different ports may export functions differently,
> or even worse, that different ports may need a different set of
> functions exported.
>
> I don't recommend using a more complicated export macro, but rather
> finding ways that WebCore doesn't need to care about diverging sets of
> exports.
>
> I believe most ports (with the exception of AppleWin/AppleMac) do not
> build WebCore as a separate dynamic library from WebKit, which makes
> exports a non-concern in the static case.
>
> In my perfect future world, WebCore would be split into many static
> libraries, and core-code -> WebKit exports would be a non-issue.  And
> of course, no embedder of core-code would ever expose core types, so
> no exports would ever need to be marked.
>
>
> On Thu, Jan 31, 2013 at 3:38 PM, Alexey Proskuryakov <ap at webkit.org>
> wrote:
> >
> > 31.01.2013, в 15:15, Dirk Pranke <dpranke at chromium.org> написал(а):
> >
> >>> I don't have concrete examples, and I don't know how big an effect on
> performance increasing the number of exports would have. It's something to
> keep an eye on, not a reason to avoid trying.
> >>
> >> I'm not parsing your reply properly -- avoid trying what? A common
> >> EXPORT macro that is set as appropriate by each port?
> >
> > Yes, you are parsing it correctly :)
> >
> > - WBR, Alexey Proskuryakov
> >
> >
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130201/e3076817/attachment.html>