On Sun, Mar 11, 2012 at 11:13 AM, Adam Barth <aba...@webkit.org> wrote: > On Sun, Mar 11, 2012 at 10:49 AM, Ami Fischman <fisch...@chromium.org> wrote: >> I'm inclined to give this thread one more business day and then call it >> Tuesday morning pacific time. >> On current showing I think the approach in the patch on the bug (incl. >> morrita@'s preference for WEBCORE_EXPORT_PRIVATE) is the way to go, at least >> for now. >> If you have strong concerns please speak up before then. > > I'm not sure I understand your proposal fully. Specifically, how > would these macros work for, say, the Chromium, Apple-Mac, and > Apple-Win ports, which export overlapping, but not identical, sets of > symbols?
Relatedly, do you plan to replace <http://trac.webkit.org/browser/trunk/Source/WebCore/WebCore.exp.in> with EXPORT macros, or will we have both macros and an export list for an extended period of time? Adam >> On Sun, Mar 11, 2012 at 3:02 AM, Hajime Morrita <morr...@chromium.org> >> wrote: >>> >>> (From the right address again...) >>> >>> On Sun, Mar 11, 2012 at 9:34 AM, Alp Toker <a...@nuanti.com> wrote: >>> > On 09/03/2012 03:52, Ami Fischman 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). >>> > >>> > >>> > I think the export macros would only ever have made sense if they were >>> > put >>> > there explicitly to guide refactoring of the classes into a library / >>> > interface structure. And this isn't the case. >>> > >>> > At present I don't see an active effort towards that, or much interest >>> > in >>> > defining the public interfaces in each 'module' more strictly. They're >>> > intentionally fluid. >>> > >>> > Having said that, the macros are /vaguely/ useful to see what could be >>> > made >>> > private or hidden in future shuffling of the code in wtf, for example, >>> > but >>> > that's about it. >>> > >>> > The very fact that the export macros have to be updated with a tool >>> > every >>> > time a library higher in the link chain uses or doesn't use a public >>> > entry >>> > point, and that the set of imported functions or variables varies >>> > between >>> > ports indicates that this is not going to have wide adoption. >>> > >>> >>> This is same for port specific export lists. >>> To keep the tree green, the community needs to maintain the list >>> regardless it is externalized from or embedded in the source. >>> And maintaining the set of export lists has larger pain than >>> maintaining a macro-based annotation. >>> Thus keeping it isolated won't help us much. >>> >>> >, and that the set of imported functions or variables varies between >>> > ports indicates that this is not going to have wide adoption. >>> >>> As mrobinson@ mentioned, there is a set of the least common denominator. >>> My guess is that the number of symbols which is different between >>> ports will be less than a half of the total. >>> If we accept such overhead, it could be a preferable option. >>> >>> > >>> > If we follow this to the logical conclusion, no unification of granular >>> > export lists is realistic with the current WebKit porting layer. If the >>> > strategy were adapted to define exported functionality at class >>> > granularity, >>> > it might just be feasible, but again that is a contract that is begging >>> > to >>> > be broken, and besides, most toolchains lack export-by-class so it's a >>> > moot >>> > point. >>> > >>> >>> At least recent gcc+ld and link.exe support such a class level annotation. >>> For GNU chain, the lack of support seems like an old story: >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9283 >>> >>> My feeling is that the macro annotation is never for declaring a "public >>> API". >>> It's just a pretty convenient replacement of the port specific export >>> lists, with small overhead from possible unwanted exports. >>> It's different from WebKit API which each port is providing. >>> There is no commitment for compatibility, as the "_PRIVATE" suffix >>> indicates. >>> >>> To clarify: I think that there should be WEBCORE_EXPORT_PRIVATE but no >>> WEBCORE_EXORT. >>> This is unlike JSC, which has both JS_EXPORT and JS_EXPORT_PRIVATE. >>> (I prefer some shorter name btw... but it's a different topic.) >>> >>> > So the ultimate course of action is then to revert the macros and leave >>> > everyone to do what they think best in terms of export lists, then tying >>> > together those solutions where there's overlap. >>> > >>> >>> So, as I wrote above, this course seems based on a wrong assumption: >>> The annotation as a public API. >>> No, it won't. It could be fluid. it would be just an internal tool >>> which only WebKit port implementations can rely on. >>> >>> Does this make sense? >>> >>> -- >>> morrita >> >> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev