<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 09/07/2018 10:56 PM, Rene Rivera
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAHEh_Ggy2r6ptgjpRtDjyKS9oqR10ze8CJnw=xw81F_dR3i6CA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=utf-8">
      <div dir="ltr">
        <div class="gmail_quote">
          <div dir="ltr">On Fri, Sep 7, 2018 at 9:16 PM Tom Honermann
            &lt;<a href="mailto:tom@honermann.net"
              moz-do-not-send="true">tom@honermann.net</a>&gt; wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">On
            09/07/2018 06:38 PM, Loïc Joly wrote:<br>
            &gt;<br>
            &gt; For closed-source library, it may not even be an
            option, but a <br>
            &gt; requirement. And I expect some of those library writers
            might be very <br>
            &gt; happy if they could avoid delivering headers, but only
            a collection of <br>
            &gt; pre-compiled module interfaces for the compilers they
            support. <br>
            <br>
            This is what I fear.  If library providers were to do that,
            tools that <br>
            are unable to consume the provided module artifacts would be
            unable to <br>
            parse any source code that has a module interface dependency
            on those <br>
            libraries.  Library providers that do this are not just
            restricting what <br>
            compilers their customers can use, they are restricting what
            tools their <br>
            customers can use on the customer's own code (at least the
            subset of it <br>
            that has a module interface dependency on the library).  I
            would <br>
            consider this a pretty user hostile thing to do.  I think we
            should make <br>
            it as easy as possible for library providers to enable their
            modular <br>
            library to work with as wide a range of tools as possible.<br>
          </blockquote>
          <div><br>
          </div>
          <div>Such library providers tend to be perfectly happy to only
            support certain tools for the libraries they distribute.
            Yes, it does restrict what users can do. But that's not
            usually a problem for their audience. The common case is
            where it's a closed platform with a single set of, usually
            proprietary, tools for it. For example in console game
            development.</div>
        </div>
      </div>
    </blockquote>
    <br>
    I have no significant experience with game development.  Is it
    typical for such providers to restrict what editors their customers
    use to write code that uses their library?  Or to restrict what
    other tools their header files can be consumed by (e.g., SWIG,
    static analyzers, etc...)?  I don't know, but I suspect restrictions
    like those are rare today.<br>
    <br>
    Tom.<br>
  </body>
</html>