It would be nice if, in the shared library build of chromium, webcore and perhaps the modules and platform were separate DLLs. On Jan 31, 2013 4:15 PM, "Eric Seidel" <[email protected]> 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 <[email protected]> > wrote: > > > > 31.01.2013, в 15:15, Dirk Pranke <[email protected]> написал(а): > > > >>> 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 > > [email protected] > > https://lists.webkit.org/mailman/listinfo/webkit-dev > _______________________________________________ > webkit-dev mailing list > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-dev >
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
