<div class="gmail_quote"><div>Responding to several emails below.</div><div><br></div><div>Adam wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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?<br>
</blockquote><div><br></div><div>I do not have a proposal to unify the export story across ports.  My "proposal" (such as it is) is limited to removing test code from the non-test webkit target (see the patch on the bug).</div>
<div>AFAICT from this thread there is no consensus on unifying options that doesn't have as its first step "achieve consensus on the complete public API of each library layer", and I didn't get the sense that this is a realistic goal, at least for me at my current level of engagement.</div>
<div><br></div><div>Adam also wrote:</div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span style>Relatedly, do you plan to replace </span><span style><</span><a href="http://trac.webkit.org/browser/trunk/Source/WebCore/WebCore.exp.in" target="_blank" class="cremed" style>http://trac.webkit.org/browser/trunk/Source/WebCore/WebCore.exp.in</a><span style>> </span><span style>with EXPORT macros, or will we have both macros and an export list for </span><span style>an extended period of time?</span></blockquote>
<div><br></div><div>The latter.  To put things in perspective, <a href="http://WebCore.exp.in">WebCore.exp.in</a> is over 2000 lines long; my patch macro-annotates ~40 classes in WebCore (which is a far cry from, say, doubling the pain of <a href="http://WebCore.exp.in">WebCore.exp.in</a>).</div>
<div>I'm also emboldened in this respect by the coexistence of WEBKIT_EXPORT and <a href="http://code.google.com/p/chromium/source/search?q=file%3AWebKit%2FSource%2FWebKit%2Fmac%2FWebKit.exp&origq=file%3AWebKit%2FSource%2FWebKit%2Fmac%2FWebKit.exp&btnG=Search+Trunk">Source/WebKit/mac/WebKit.exp</a>.</div>
<div><br></div><div>Alp wrote:</div><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Doesn't the list of exports change massively based on the level of inlining and compiler optimisation? Which configuration is the target to aim for, and which compiler vendor?</blockquote><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Doesn't the list also change between releases of the same compiler?<br></blockquote><div><br></div><div>AFAICT the answers to your questions are all "no", for the limited scope of my change (some indication of this is that I only tested my patch on chromium/linux, but it's now green on all EWS bots after only needing to add #include's to get the definition of the export macro, not due to having to add extra annotations for some ports).</div>
<div>As with the existing JSC_EXPORT and WEBKIT_EXPORT macros, the new WEBCORE_EXPORT_PRIVATE (nee (unused) WEBKIT_EXPORTDATA) will be an annotation added by whoever lands a patch that requires access to something from outside the library that today doesn't require it.  </div>
<div><br></div><div>Ash proposed replacing both the explicit post-mangled export lists and in-line macros with per-port export-lists that would be used at build time to emit modified headers.  I'd have to see a PoC of this to believe that it wouldn't combine the worst aspects of all the options on the table ;)  The proposal assumes a lot of things I don't believe are <u>strictly</u> true, and I believe the gap between "almost right" and "strictly right" is where enough pain will come from to sink this option.</div>
<div><br></div><div>Cheers,</div><div>-a</div></div>