<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 09/03/2012 03:52, Ami Fischman wrote:
    <blockquote
cite="mid:CAHuR8a90pJVK1=L2JVCoGxuthG6C6nR-3SPg1sK6tVaA-s9oZw@mail.gmail.com"
      type="cite">Hi webkittens,
      <div><br>
      </div>
      <div>The over-all question: how should webkit libraries declare
        which symbols they export?</div>
      <div>The trigger for the question: as described in <a
          moz-do-not-send="true"
          href="https://bugs.webkit.org/show_bug.cgi?id=80062">bug 80062</a>,
        the chromium shared-library-based build links test code into the
        (non-test) libwebkit.so target, which is terrible.</div>
      <div><br>
      </div>
      <div>The details:</div>
      <div>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 (<a
          moz-do-not-send="true"
href="http://code.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/JavaScriptCore/wtf/ExportMacros.h&exact_package=chromium&q=WTF_EXPORT&type=cs&l=39">WTF</a>, <a
          moz-do-not-send="true"
href="http://code.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/Platform/chromium/public/WebCommon.h&exact_package=chromium&q=WEBKIT_EXPORT&l=68">Platform</a>, <a
          moz-do-not-send="true"
href="http://code.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/platform/PlatformExportMacros.h&exact_package=chromium&q=define%5C%20WEBKIT_EXPORT&ct=rc&cd=2&sq=&l=39">WebCore</a>,
        and <a moz-do-not-send="true"
href="http://code.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebKit/chromium/public/platform/WebCommon.h&exact_package=chromium&q=file:%28%5E%7C/%29platform/WebCommon%5C.h$">WebKit</a>,
        AFAICT), and incidentally also what the chromium project uses
        for its sub-components.  </div>
      <div>But I'm told other ports use different mechanisms such as <a
          moz-do-not-send="true"
href="http://code.google.com/p/chromium/source/search?q=file%3ASource%2FWebCore%2FWebCore.exp.in&origq=file%3ASource%2FWebCore%2FWebCore.exp.in&btnG=Search+Trunk">.exp.in
          files</a> for apple/mac (and maybe others for other ports?
        IDK).</div>
      <div><br>
      </div>
      <div>Is there consensus on the list for what the Right Thing To
        Do(tm) is?</div>
      <div>ISTM my options are:</div>
      <div>1) Add EXPORT declarations as in the patch on the bug.</div>
      <div>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.</div>
      <div>3) Something else (preferably unifying other ports'
        approaches).</div>
      <div><br>
      </div>
      <div>Help me webkit-dev, you're my only hope (for consensus).</div>
      <div><br>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    The exception is, of course, clearly defined public API (of which
    there is not much), such as this case where we added JS_EXPORT to
    the JavaScriptCore API for the benefit of multiple ports and also
    consumers: <a href="http://trac.webkit.org/changeset/28097">http://trac.webkit.org/changeset/28097</a><br>
    <br>
    (In a port I worked on in the past we developed a vendor tool to
    detect inter-dependencies at compile time so there were no lists to
    update, but again, this would not be portable.)<br>
    <br>
    Spoken with my devil's advocate hat on, would be great if you can
    prove me wrong.<br>
    <br>
    <pre class="moz-signature" cols="72">-- 
<a class="moz-txt-link-freetext" href="http://www.nuanti.com">http://www.nuanti.com</a>
the browser experts</pre>
  </body>
</html>