Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))
On Sun, Feb 3, 2013 at 7:29 AM, Benjamin Poulain benja...@webkit.orgwrote: On Sat, Feb 2, 2013 at 10:23 PM, Eric Seidel e...@webkit.org 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))
On Feb 4, 2013, at 12:17 AM, Jochen Eisinger joc...@chromium.org wrote: On Sun, Feb 3, 2013 at 7:29 AM, Benjamin Poulain benja...@webkit.org wrote: On Sat, Feb 2, 2013 at 10:23 PM, Eric Seidel e...@webkit.org 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))
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))
On Fri, Feb 1, 2013 at 5:12 PM, Balazs Kelemen kbal...@webkit.org 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-devhttps://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))
On Sat, Feb 2, 2013 at 4:16 PM, James Robinson jam...@google.com wrote: On Fri, Feb 1, 2013 at 5:12 PM, Balazs Kelemen kbal...@webkit.org 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-devhttps://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))
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 mrobin...@webkit.orgwrote: On Thu, Jan 31, 2013 at 5:39 PM, Ryosuke Niwa rn...@webkit.org 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))
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 e...@webkit.org 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 mrobin...@webkit.orgwrote: On Thu, Jan 31, 2013 at 5:39 PM, Ryosuke Niwa rn...@webkit.org 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))
On Sat, Feb 2, 2013 at 10:23 PM, Eric Seidel e...@webkit.org 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))
(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 ryosuke.n...@gmail.comwrote: On Wed, Jan 30, 2013 at 11:33 PM, Jochen Eisinger joc...@chromium.orgwrote: On Thu, Jan 31, 2013 at 1:15 AM, Maciej Stachowiak m...@apple.com wrote: On Jan 30, 2013, at 3:24 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote: Thanks for sharing this. On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org 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
Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))
On Thu, Jan 31, 2013 at 12:09 AM, Hajime Morrita morr...@google.com 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))
On Thu, Jan 31, 2013 at 9:43 AM, Alexey Proskuryakov a...@apple.com wrote: 31.01.2013, в 0:17, Ryosuke Niwa rn...@webkit.org написал(а): 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))
On Thu, Jan 31, 2013 at 9:48 AM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Jan 31, 2013 at 9:43 AM, Alexey Proskuryakov a...@apple.com wrote: 31.01.2013, в 0:17, Ryosuke Niwa rn...@webkit.org написал(а): 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))
31.01.2013, в 14:45, Dirk Pranke dpra...@chromium.org написал(а): 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))
On Thu, Jan 31, 2013 at 2:52 PM, Alexey Proskuryakov a...@apple.com wrote: 31.01.2013, в 14:45, Dirk Pranke dpra...@chromium.org написал(а): 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))
31.01.2013, в 14:57, Dirk Pranke dpra...@chromium.org написал(а): 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))
On Thu, Jan 31, 2013 at 2:57 PM, Dirk Pranke dpra...@chromium.org wrote: On Thu, Jan 31, 2013 at 2:52 PM, Alexey Proskuryakov a...@apple.com wrote: 31.01.2013, в 14:45, Dirk Pranke dpra...@chromium.org написал(а): 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))
On Thu, Jan 31, 2013 at 3:12 PM, Alexey Proskuryakov a...@webkit.org wrote: 31.01.2013, в 14:57, Dirk Pranke dpra...@chromium.org написал(а): 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))
31.01.2013, в 15:15, Dirk Pranke dpra...@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@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))
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 a...@webkit.org wrote: 31.01.2013, в 15:15, Dirk Pranke dpra...@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@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))
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 e...@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 a...@webkit.org wrote: 31.01.2013, в 15:15, Dirk Pranke dpra...@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@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))
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 e...@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 a...@webkit.org wrote: 31.01.2013, в 15:15, Dirk Pranke dpra...@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@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))
On Thu, Jan 31, 2013 at 5:20 PM, Hajime Morrita morr...@chromium.orgwrote: 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))
On Thu, Jan 31, 2013 at 5:39 PM, Ryosuke Niwa rn...@webkit.org 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))
On Fri, Feb 1, 2013 at 10:39 AM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Jan 31, 2013 at 5:20 PM, Hajime Morrita morr...@chromium.orgwrote: 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
