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