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.
Cheers, -a On Sun, Mar 11, 2012 at 3:02 AM, Hajime Morrita <[email protected]>wrote: > (From the right address again...) > > On Sun, Mar 11, 2012 at 9:34 AM, Alp Toker <[email protected]> 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.infiles 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 [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
