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

[Maciej Stachowiak]

On Feb 4, 2013, at 12:17 AM, Jochen Eisinger  wrote:

> 
> 
> On Sun, Feb 3, 2013 at 7:29 AM, Benjamin Poulain  wrote:
> On Sat, Feb 2, 2013 at 10:23 PM, Eric Seidel  wrote:
> What I've learned from this thread, is that AppleWin and AppleMac are the 
> only two ports which require lists of exported symbols.  If both were to 
> convert to using EXPORT decorators instead, then we could remove needs for 
> fixing export lists.
> 
> Please correct me if I've misunderstood.
> 
> There is also iOS. The export file contains both Mac and iOS, they do not 
> export the same symbols.
> 
> There is unfortunately a need to have different exports for per platform; the 
> syntax will probably have to account for that.
> 
> Just to clarify: there's code that is used on e.g. Mac but not iOS, but it's 
> still compiled into the iOS port (i.e. not disabled by some feature macro 
> anyway)?

The WebKit layers aren't identical and may need different WebCore exports, but 
it's probably ok (not totally sure) to export every actually existing symbol 
that needs to be exported on either platform. WebCore is a private subframework 
anyway so keeping its exports clean is not super important.

 - Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Jochen Eisinger]

On Sun, Feb 3, 2013 at 7:29 AM, Benjamin Poulain wrote:

> On Sat, Feb 2, 2013 at 10:23 PM, Eric Seidel  wrote:
>
>> What I've learned from this thread, is that AppleWin and AppleMac are the
>> only two ports which require lists of exported symbols.  If both were to
>> convert to using EXPORT decorators instead, then we could remove needs for
>> fixing export lists.
>>
>> Please correct me if I've misunderstood.
>>
>
> There is also iOS. The export file contains both Mac and iOS, they do not
> export the same symbols.
>
>  There is unfortunately a need to have different exports for per platform;
> the syntax will probably have to account for that.
>

Just to clarify: there's code that is used on e.g. Mac but not iOS, but
it's still compiled into the iOS port (i.e. not disabled by some feature
macro anyway)?

best
-jochen



>
> Benjamin
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Benjamin Poulain]

On Sat, Feb 2, 2013 at 10:23 PM, Eric Seidel  wrote:

> What I've learned from this thread, is that AppleWin and AppleMac are the
> only two ports which require lists of exported symbols.  If both were to
> convert to using EXPORT decorators instead, then we could remove needs for
> fixing export lists.
>
> Please correct me if I've misunderstood.
>

There is also iOS. The export file contains both Mac and iOS, they do not
export the same symbols.

There is unfortunately a need to have different exports for per platform;
the syntax will probably have to account for that.

Benjamin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Eric Seidel]

I should have been more clear.  By "which require lists of exported
symbols", I meant "which require lists of exported symbols for WebCore".
 The Internals discussion is obviously about WebCore symbols which are
exported through WebKit as well.  It seems no other symbols from WebCore
should ever be exported from WebKit on any port besides "Internals" symbols.

On Sat, Feb 2, 2013 at 10:23 PM, Eric Seidel  wrote:

> What I've learned from this thread, is that AppleWin and AppleMac are the
> only two ports which require lists of exported symbols.  If both were to
> convert to using EXPORT decorators instead, then we could remove needs for
> fixing export lists.
>
> Please correct me if I've misunderstood.
>
> Other ports (including GTK), it seems need an internals-specific export
> macro, in order to export window.internals necessary symbols from their
> WebKit dynamic library.  I believe this is true of all ports (with the
> possible exception of Chromium).
>
>
> On Thu, Jan 31, 2013 at 5:55 PM, Martin Robinson wrote:
>
>> On Thu, Jan 31, 2013 at 5:39 PM, Ryosuke Niwa  wrote:
>> > Doesn't GTK+ port also require symbol exports for WebKit2? In
>> particular, I
>> > thought all symbols used in Internals need to be exported there.
>>
>> WebKitGTK+ does not need to export symbols from WebCore for WebKit2,
>> because WebCore is built as a static convenience library. We do need
>> to export symbols for the Internals library because it's built as a
>> separate object that links against libwebkitgtk. Adding an export
>> macro for Internals would be great for us, since we wouldn't have to
>> export so many symbols via Source/autotools/symbols.filter. It would
>> also decrease the maintenance burden for non-GTK+ port contributors.
>>
>> --Martin
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Eric Seidel]

What I've learned from this thread, is that AppleWin and AppleMac are the
only two ports which require lists of exported symbols.  If both were to
convert to using EXPORT decorators instead, then we could remove needs for
fixing export lists.

Please correct me if I've misunderstood.

Other ports (including GTK), it seems need an internals-specific export
macro, in order to export window.internals necessary symbols from their
WebKit dynamic library.  I believe this is true of all ports (with the
possible exception of Chromium).


On Thu, Jan 31, 2013 at 5:55 PM, Martin Robinson wrote:

> On Thu, Jan 31, 2013 at 5:39 PM, Ryosuke Niwa  wrote:
> > Doesn't GTK+ port also require symbol exports for WebKit2? In
> particular, I
> > thought all symbols used in Internals need to be exported there.
>
> WebKitGTK+ does not need to export symbols from WebCore for WebKit2,
> because WebCore is built as a static convenience library. We do need
> to export symbols for the Internals library because it's built as a
> separate object that links against libwebkitgtk. Adding an export
> macro for Internals would be great for us, since we wouldn't have to
> export so many symbols via Source/autotools/symbols.filter. It would
> also decrease the maintenance burden for non-GTK+ port contributors.
>
> --Martin
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Darin Fisher]

On Sat, Feb 2, 2013 at 4:16 PM, James Robinson  wrote:

>
>
> On Fri, Feb 1, 2013 at 5:12 PM, Balazs Kelemen  wrote:
>
>> On 02/01/2013 02:28 AM, Darin Fisher wrote:
>>
>>>
>>> It would be nice if, in the shared library build of chromium, webcore
>>> and perhaps the modules and platform were separate DLLs.
>>>
>>>
>> The shared library build is kind of a developer build, right? In this
>> case I believe you can solve this by setting the default visibility to
>> public at compiler/linker level, no need for exports.
>>
>
> That doesn't work on windows.
>
>
Right.

Yes, the shared library build of Chromium is a developer-only build mode.
 It is helpful to split the project up into separate DLLs to reduce build
times and to help enforce correct dependencies between modules.

-Darin



> - James
>
>
>>
>> -kbalazs
>>
>> __**_
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/**mailman/listinfo/webkit-dev
>>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[James Robinson]

On Fri, Feb 1, 2013 at 5:12 PM, Balazs Kelemen  wrote:

> On 02/01/2013 02:28 AM, Darin Fisher wrote:
>
>>
>> It would be nice if, in the shared library build of chromium, webcore and
>> perhaps the modules and platform were separate DLLs.
>>
>>
> The shared library build is kind of a developer build, right? In this case
> I believe you can solve this by setting the default visibility to public at
> compiler/linker level, no need for exports.
>

That doesn't work on windows.

- James


>
> -kbalazs
>
> __**_
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/**mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Balazs Kelemen]

On 02/01/2013 02:28 AM, Darin Fisher wrote:


It would be nice if, in the shared library build of chromium, webcore 
and perhaps the modules and platform were separate DLLs.




The shared library build is kind of a developer build, right? In this 
case I believe you can solve this by setting the default visibility to 
public at compiler/linker level, no need for exports.


-kbalazs
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Hajime Morrita]

On Fri, Feb 1, 2013 at 10:39 AM, Ryosuke Niwa  wrote:

> On Thu, Jan 31, 2013 at 5:20 PM, Hajime Morrita wrote:
>
>> 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.
>>
>
> Doesn't GTK+ port also require symbol exports for WebKit2? In particular,
> I thought all symbols used in Internals need to be exported there.
>

Ouch, I'm sorry for the unclear explanation.
This is what I meant say as "one exception" above. WebCoreTesting includes
Internals, which requires some exported symbols,
which could be (IMO) covered by WEBCORE_TESTING_EXPORT or some separate
macro.


> - R. Niwa
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Martin Robinson]

On Thu, Jan 31, 2013 at 5:39 PM, Ryosuke Niwa  wrote:
> Doesn't GTK+ port also require symbol exports for WebKit2? In particular, I
> thought all symbols used in Internals need to be exported there.

WebKitGTK+ does not need to export symbols from WebCore for WebKit2,
because WebCore is built as a static convenience library. We do need
to export symbols for the Internals library because it's built as a
separate object that links against libwebkitgtk. Adding an export
macro for Internals would be great for us, since we wouldn't have to
export so many symbols via Source/autotools/symbols.filter. It would
also decrease the maintenance burden for non-GTK+ port contributors.

--Martin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Ryosuke Niwa]

On Thu, Jan 31, 2013 at 5:20 PM, Hajime Morrita wrote:

> 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.
>

Doesn't GTK+ port also require symbol exports for WebKit2? In particular, I
thought all symbols used in Internals need to be exported there.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Darin Fisher]

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"  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 
> wrote:
> >
> > 31.01.2013, в 15:15, Dirk Pranke  написал(а):
> >
> >>> 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@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [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  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 
> wrote:
> >
> > 31.01.2013, в 15:15, Dirk Pranke  написал(а):
> >
> >>> 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@lists.webkit.org
> > https://lists.webkit.org/mailman/listinfo/webkit-dev
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Eric Seidel]

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  wrote:
>
> 31.01.2013, в 15:15, Dirk Pranke  написал(а):
>
>>> 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@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Alexey Proskuryakov]

31.01.2013, в 15:15, Dirk Pranke  написал(а):

>> 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@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Dirk Pranke]

On Thu, Jan 31, 2013 at 3:12 PM, Alexey Proskuryakov  wrote:
>
> 31.01.2013, в 14:57, Dirk Pranke  написал(а):
>
>> One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
>> the number of exports for each port, because it would export symbols that
>> are only needed for other ports.
>

 I'm not sure I understand the concern here. Is the idea that some
 ports might build WebCore as a DLL (and need exports) and others
 wouldn't? Or the idea that the API that is needed to be exported might
 vary from port to port in such a way that too many symbols for WebCore
 might be exported on some ports?
>>>
>>> The latter.
>>>
>>> I suspect that it's somewhat less of an issue for JavaScriptCore, because 
>>> its exports are mostly used from cross-platform code.
>>>
>>
>> I see. Some concrete examples would be helpful here (to me, at least).
>> What components and ports are we talking about, and what sorts of
>> symbols?
>
> 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?

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Ryosuke Niwa]

On Thu, Jan 31, 2013 at 2:57 PM, Dirk Pranke  wrote:

> On Thu, Jan 31, 2013 at 2:52 PM, Alexey Proskuryakov  wrote:
> >
> > 31.01.2013, в 14:45, Dirk Pranke  написал(а):
> >
>  One thing to keep an eye on with WEBCORE_EXPORT is that it can
> increase
>  the number of exports for each port, because it would export symbols
> that
>  are only needed for other ports.
> >>>
> >>
> >> I'm not sure I understand the concern here. Is the idea that some
> >> ports might build WebCore as a DLL (and need exports) and others
> >> wouldn't? Or the idea that the API that is needed to be exported might
> >> vary from port to port in such a way that too many symbols for WebCore
> >> might be exported on some ports?
> >
> > The latter.
> >
> > I suspect that it's somewhat less of an issue for JavaScriptCore,
> because its exports are mostly used from cross-platform code.
> >
>
> I see. Some concrete examples would be helpful here (to me, at least).
> What components and ports are we talking about, and what sorts of
> symbols?
>

FWIW, there are quite few symbols exported from EditorMac.mm although of
them are if-def PLATFORM(MAC)'ed in .h anyway.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Alexey Proskuryakov]

31.01.2013, в 14:57, Dirk Pranke  написал(а):

> One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
> the number of exports for each port, because it would export symbols that
> are only needed for other ports.
 
>>> 
>>> I'm not sure I understand the concern here. Is the idea that some
>>> ports might build WebCore as a DLL (and need exports) and others
>>> wouldn't? Or the idea that the API that is needed to be exported might
>>> vary from port to port in such a way that too many symbols for WebCore
>>> might be exported on some ports?
>> 
>> The latter.
>> 
>> I suspect that it's somewhat less of an issue for JavaScriptCore, because 
>> its exports are mostly used from cross-platform code.
>> 
> 
> I see. Some concrete examples would be helpful here (to me, at least).
> What components and ports are we talking about, and what sorts of
> symbols?

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.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Dirk Pranke]

On Thu, Jan 31, 2013 at 2:52 PM, Alexey Proskuryakov  wrote:
>
> 31.01.2013, в 14:45, Dirk Pranke  написал(а):
>
 One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
 the number of exports for each port, because it would export symbols that
 are only needed for other ports.
>>>
>>
>> I'm not sure I understand the concern here. Is the idea that some
>> ports might build WebCore as a DLL (and need exports) and others
>> wouldn't? Or the idea that the API that is needed to be exported might
>> vary from port to port in such a way that too many symbols for WebCore
>> might be exported on some ports?
>
> The latter.
>
> I suspect that it's somewhat less of an issue for JavaScriptCore, because its 
> exports are mostly used from cross-platform code.
>

I see. Some concrete examples would be helpful here (to me, at least).
What components and ports are we talking about, and what sorts of
symbols?

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Alexey Proskuryakov]

31.01.2013, в 14:45, Dirk Pranke  написал(а):

>>> One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
>>> the number of exports for each port, because it would export symbols that
>>> are only needed for other ports.
>> 
> 
> I'm not sure I understand the concern here. Is the idea that some
> ports might build WebCore as a DLL (and need exports) and others
> wouldn't? Or the idea that the API that is needed to be exported might
> vary from port to port in such a way that too many symbols for WebCore
> might be exported on some ports?

The latter.

I suspect that it's somewhat less of an issue for JavaScriptCore, because its 
exports are mostly used from cross-platform code.

- WBR, Alexey Proskuryakov


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Dirk Pranke]

On Thu, Jan 31, 2013 at 9:48 AM, Ryosuke Niwa  wrote:
> On Thu, Jan 31, 2013 at 9:43 AM, Alexey Proskuryakov  wrote:
>>
>>
>> 31.01.2013, в 0:17, Ryosuke Niwa  написал(а):
>>
>>> I did it for WTF and JSC with kevino@.
>>> https://bugs.webkit.org/show_bug.cgi?id=72855
>>> I hope I had had time to extend the work to WebCore, which was my
>>> original goal :-/
>>>
>>> I did it through an automation but the tool was so slow and hacky that it
>>> was not capable for large WebCore codebase.
>>>
>>> Seeing that the number of exported symbol is about 2700, manual work with
>>> regular expression will also work
>>> if it is OK to do the work incrementally... and if you are patient enough
>>> :-)
>>
>>
>> 2700 is a lot of symbols to export! Perhaps we can reduce the number of
>> exported symbols? For example, we can move more code from WebKit into
>> WebCore to share more code between ports so that the API surface WebCore has
>> to expose will be smaller and more well defined.
>>
>>
>> One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
>> the number of exports for each port, because it would export symbols that
>> are only needed for other ports.
>

I'm not sure I understand the concern here. Is the idea that some
ports might build WebCore as a DLL (and need exports) and others
wouldn't? Or the idea that the API that is needed to be exported might
vary from port to port in such a way that too many symbols for WebCore
might be exported on some ports?

>
> Can we make the macro starter and specify ports under which a given symbol
> needs to be exported? e.g. WEBCORE_EXPORT(MAC, QT)
>

I'm not sure how this helps, but I think that's because of my previous
comment. I could see something like this maybe being needed in my
later scenario (where MAC might need a symbol exported from WebCore
that Qt needed to keep from being exported)?

Is that a hard requirement, or an optimization?

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Ryosuke Niwa]

On Thu, Jan 31, 2013 at 9:43 AM, Alexey Proskuryakov  wrote:

>
> 31.01.2013, в 0:17, Ryosuke Niwa  написал(а):
>
>  I did it for WTF and JSC with kevino@.
>> https://bugs.webkit.org/show_bug.cgi?id=72855
>> I hope I had had time to extend the work to WebCore, which was my
>> original goal :-/
>>
>> I did it through an automation but the tool was so slow and hacky that it
>> was not capable for large WebCore codebase.
>>
>> Seeing that the number of exported symbol is about 2700, manual work with
>> regular expression will also work
>> if it is OK to do the work incrementally... and if you are patient enough
>> :-)
>>
>
> 2700 is a lot of symbols to export! Perhaps we can reduce the number of
> exported symbols? For example, we can move more code from WebKit into
> WebCore to share more code between ports so that the API surface WebCore
> has to expose will be smaller and more well defined.
>
>
> One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
> the number of exports for each port, because it would export symbols that
> are only needed for other ports.
>

Can we make the macro starter and specify ports under which a given symbol
needs to be exported? e.g. WEBCORE_EXPORT(MAC, QT)

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Ryosuke Niwa]

On Thu, Jan 31, 2013 at 12:09 AM, Hajime Morrita  wrote:

> I did it for WTF and JSC with kevino@.
> https://bugs.webkit.org/show_bug.cgi?id=72855
> I hope I had had time to extend the work to WebCore, which was my original
> goal :-/
>
> I did it through an automation but the tool was so slow and hacky that it
> was not capable for large WebCore codebase.
>
> Seeing that the number of exported symbol is about 2700, manual work with
> regular expression will also work
> if it is OK to do the work incrementally... and if you are patient enough
> :-)
>

2700 is a lot of symbols to export! Perhaps we can reduce the number of
exported symbols? For example, we can move more code from WebKit into
WebCore to share more code between ports so that the API surface WebCore
has to expose will be smaller and more well defined.

I also bet there are quite few symbols we export from WebCore that are no
longer used in WebKit.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[Hajime Morrita]

(From the right address)

I did it for WTF and JSC with kevino@.
https://bugs.webkit.org/show_bug.cgi?id=72855
I hope I had had time to extend the work to WebCore, which was my original
goal :-/

I did it through an automation but the tool was so slow and hacky that it
was not capable for large WebCore codebase.

Seeing that the number of exported symbol is about 2700, manual work with
regular expression will also work
if it is OK to do the work incrementally... and if you are patient enough
:-)

--
morrita



On Thu, Jan 31, 2013 at 4:39 PM, Ryosuke Niwa wrote:

> On Wed, Jan 30, 2013 at 11:33 PM, Jochen Eisinger wrote:
>
>> On Thu, Jan 31, 2013 at 1:15 AM, Maciej Stachowiak  wrote:
>>
>>> On Jan 30, 2013, at 3:24 PM, Dirk Pranke  wrote:
>>>
>>> > On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo  wrote:
>>> >> Thanks for sharing this.
>>> >>
>>> >> On Jan 30, 2013, at 1:28 PM, Eric Seidel  wrote:
>>> >>
>>> >> I wish we only had one build system (it were easy to add/remove/move
>>> files).
>>> >>
>>> >> I believe changes like http://trac.webkit.org/changeset/74849 are an
>>> >> unhealthy sign for the project.  Adam is not the only person who has
>>> chosen
>>> >> to empty files instead of removing them.  The pain of updating 8 build
>>> >> system is so great, we jump through hoops to avoid it.  Which means
>>> it took
>>> >> us months to move JavaScriptCore/wtf to WTF, and will take us years
>>> to kill
>>> >> WebCore/platform.
>>> >>
>>> >>
>>> >> +1
>>> >>
>>> >> This is a hard problem.  It is a problem worth solving.
>>> >>
>>> >> Do you have more thoughts on this, particularly since you know quite
>>> well
>>> >> how both Xcode and gyp work?
>>> >>
>>> >> I suspect this is one of those things that it would be hard to achieve
>>> >> consensus on since there are so many stakeholders.  But it may be
>>> fruitful
>>> >> to have a "what if" discussion about what this might look like.
>>> >>
>>> >
>>> > I think we can solve this problem if we agree that we want to. I think
>>> > we haven't in the past mostly because we couldn't reach a consensus
>>> > that it was worth solving enough to really try.
>>> >
>>> > I would love to see this fixed and would be glad to work on it. I
>>> > think we should at least pursue this far enough to fully understand
>>> > what our options are and what the costs and tradeoffs might be; does
>>> > anyone disagree, and is anyone else willing to help pitch in?
>>> >
>>> > I think there are several possible ways we could solve this. One would
>>> > be to switch to a common meta-build system. My understanding is that
>>> > Apple's internal production build processes impose certain constraints
>>> > here that I don't fully understand, but I know we've discussed the
>>> > possibility of checking in generated project files as a workaround.
>>> > Maybe there are other options as well to those constraints? I would
>>> > love to discuss this further w/ someone from Apple ...
>>>
>>> It's far simplest for us if:
>>> (a) There is an Xcode project (or a Makefile) that builds the Mac port
>>> checked in to source control.
>>> (b) The generated project invokes only tools that are part of the
>>> default Mac OS X install.
>>>
>>
>> Another desirable property would be to move to a more automatic way of
>> handling exported symbols: Currently each port that depends on this feature
>> has its own .exp file or similar. I think if we could move to something
>> that would allow for changing WebCore API without having to touch all those
>> files, e.g. by consistently using WEBCORE_EXPORT macros would be a big win
>>
>
> morrita already did this for WTF, and it works great for us. What's
> blocking us from doing the same for WebCore?
>
> - R. Niwa
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev