<div>I'm inclined to give this thread one more business day and then call it Tuesday morning pacific time.  </div>
<div>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.  </div><div>If you have strong concerns please speak up before then.</div>
<div><br></div><div>Cheers,</div><div>-a<br>
<br><div class="gmail_quote">On Sun, Mar 11, 2012 at 3:02 AM, Hajime Morrita <span dir="ltr"><<a href="mailto:morrita@chromium.org" target="_blank">morrita@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

(From the right address again...)<br>
<div><br>
On Sun, Mar 11, 2012 at 9:34 AM, Alp Toker <<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>> wrote:<br>
</div><div><div>> On 09/03/2012 03:52, Ami Fischman wrote:<br>
><br>
> Hi webkittens,<br>
><br>
> The over-all question: how should webkit libraries declare which symbols<br>
> they export?<br>
> The trigger for the question: as described in bug 80062, the chromium<br>
> shared-library-based build links test code into the (non-test) libwebkit.so<br>
> target, which is terrible.<br>
><br>
> The details:<br>
> I took a crack at fixing the above bug (see patch in the bug) by pulling the<br>
> test files out of the non-test build target, and sprinkling various<br>
> {WTF,WEBKIT}_EXPORT{,DATA} macros around declarations that need them (as<br>
> discovered by build-time and run-time failures).  This style of export<br>
> declaration is what the webkit codebase does in various places<br>
> (WTF, Platform, WebCore, and WebKit, AFAICT), and incidentally also what<br>
> the chromium project uses for its sub-components.<br>
> But I'm told other ports use different mechanisms such as .<a href="http://exp.in" target="_blank">exp.in</a> files for<br>
> apple/mac (and maybe others for other ports? IDK).<br>
><br>
> Is there consensus on the list for what the Right Thing To Do(tm) is?<br>
> ISTM my options are:<br>
> 1) Add EXPORT declarations as in the patch on the bug.<br>
> 2) Drop the patch from the bug and replace it with chromium-specific<br>
> .exp.in-style files, one per layer from which I need to export (WebCore,<br>
> WTF, WebKit).  And build the build-time machinery to use them.  I don't<br>
> really know what's involved here and would appreciate any pointers/hints<br>
> people had if this is the way to go.<br>
> 3) Something else (preferably unifying other ports' approaches).<br>
><br>
> Help me webkit-dev, you're my only hope (for consensus).<br>
><br>
><br>
> I think the export macros would only ever have made sense if they were put<br>
> there explicitly to guide refactoring of the classes into a library /<br>
> interface structure. And this isn't the case.<br>
><br>
> At present I don't see an active effort towards that, or much interest in<br>
> defining the public interfaces in each 'module' more strictly. They're<br>
> intentionally fluid.<br>
><br>
> Having said that, the macros are /vaguely/ useful to see what could be made<br>
> private or hidden in future shuffling of the code in wtf, for example, but<br>
> that's about it.<br>
><br>
> The very fact that the export macros have to be updated with a tool every<br>
> time a library higher in the link chain uses or doesn't use a public entry<br>
> point, and that the set of imported functions or variables varies between<br>
> ports indicates that this is not going to have wide adoption.<br>
><br>
<br>
</div></div><div>This is same for port specific export lists.<br>
To keep the tree green, the community needs to maintain the list<br>
regardless it is externalized from or embedded in the source.<br>
And maintaining the set of export lists has larger pain than<br>
maintaining a macro-based annotation.<br>
Thus keeping it isolated won't help us much.<br>
<br>
</div><div>>, and that the set of imported functions or variables varies between<br>
> ports indicates that this is not going to have wide adoption.<br>
<br>
</div><div>As mrobinson@ mentioned, there is a set of the least common denominator.<br>
My guess is that the number of symbols which is different between<br>
ports will be less than a half of the total.<br>
If we accept such overhead, it could be a preferable option.<br>
<br>
><br>
</div><div>> If we follow this to the logical conclusion, no unification of granular<br>
> export lists is realistic with the current WebKit porting layer. If the<br>
> strategy were adapted to define exported functionality at class granularity,<br>
> it might just be feasible, but again that is a contract that is begging to<br>
> be broken, and besides, most toolchains lack export-by-class so it's a moot<br>
> point.<br>
><br>
<br>
</div><div>At least recent gcc+ld and link.exe support such a class level annotation.<br>
For GNU chain, the lack of support seems like an old story:<br>
<a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9283" target="_blank">http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9283</a><br>
<br>
My feeling is that the macro annotation is never for declaring a "public API".<br>
It's just a pretty convenient replacement of the port specific export<br>
lists, with small overhead from possible unwanted exports.<br>
It's different from WebKit API which each port is providing.<br>
There is no commitment for compatibility, as the "_PRIVATE" suffix indicates.<br>
<br>
To clarify: I think that there should be WEBCORE_EXPORT_PRIVATE but no<br>
WEBCORE_EXORT.<br>
This is unlike JSC, which has both JS_EXPORT and JS_EXPORT_PRIVATE.<br>
(I prefer some shorter name btw... but it's a different topic.)<br>
<br>
</div><div>> So the ultimate course of action is then to revert the macros and leave<br>
> everyone to do what they think best in terms of export lists, then tying<br>
> together those solutions where there's overlap.<br>
><br>
<br>
</div><div><div>So, as I wrote above, this course seems based on a wrong assumption:<br>
The annotation as a public API.<br>
No, it won't. It could be fluid. it would be just an internal tool<br>
which only WebKit port implementations can rely on.<br>
<br>
Does this make sense?<br>
<br>
--<br>
morrita<br>
</div></div></blockquote></div><br></div>