<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 08/01/2023 18:37, Martin Pernollet
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:hBvEIib04s0_78Mp77MrJvqim5gpc4Cklamed93VsCR1PajJOtMkyiZDSuJfycx_Koo9GvqTyAAT4VRK1MearIzLN5WbxV8bgLOfGARDBQQ=@protonmail.com">
      
      <div style="font-family: Arial; font-size: 14px;">Thank you
        Duncan!</div>
      <div style="font-family: Arial; font-size: 14px;"><br>
      </div>
      <div style="font-family: Arial; font-size: 14px;">I did something
        similar : take the binding generated for Ubuntu and use them on
        macOS and it was working properly. </div>
      <div style="font-family: Arial; font-size: 14px;"><br>
      </div>
      <div style="font-family: Arial; font-size: 14px;">I only add to
        comment loading of the library inside glut_h and do it at my
        application startup so that it uses macOS path rather than the
        linux one.</div>
    </blockquote>
    Hi Martin,<br>
    <p>perhaps a better approach would be to not pass any "-l" (lower
      case "L") to jextract, so that no library name/path is hardwired
      in the generated bindings.</p>
    <p>Then your application logic could, inside a static initializer,
      set up the required libraries, via System::loadLibrary.</p>
    <p>But we know jextract needs to do more in this area, and have some
      way for developers to "plug in" their own symbol lookup object. We
      have a bug for this:</p>
    <p><a class="moz-txt-link-freetext" href="https://bugs.openjdk.org/browse/CODETOOLS-7903186">https://bugs.openjdk.org/browse/CODETOOLS-7903186</a></p>
    <p>In principle, we could "just" use a service loader - in practice
      this is more difficult, given that a service loader implies that
      there is some jextract "runtime" library (e.g. a jar) available
      when you run your application code. For now we have tried to avoid
      this (e.g. requiring dependencies on runtime libraries) so that
      the jextract experience could be simpler/more direct.</p>
    <p>Maurizio<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:hBvEIib04s0_78Mp77MrJvqim5gpc4Cklamed93VsCR1PajJOtMkyiZDSuJfycx_Koo9GvqTyAAT4VRK1MearIzLN5WbxV8bgLOfGARDBQQ=@protonmail.com">
      <div style="font-family: Arial; font-size: 14px;"><br>
      </div>
      <div style="font-family: Arial; font-size: 14px;">Regards,</div>
      <div style="font-family: Arial; font-size: 14px;"><br>
      </div>
      <div style="font-family: Arial; font-size: 14px;">Martin</div>
      <div class="protonmail_quote"> ------- Original Message -------<br>
        Le dimanche 8 janvier 2023 à 19:24, Duncan Gittins
        <a class="moz-txt-link-rfc2396E" href="mailto:duncan.gittins@gmail.com"><duncan.gittins@gmail.com></a> a écrit :<br>
        <br>
        <blockquote class="protonmail_quote" type="cite">
          <div class="moz-cite-prefix">For what its worth, I was
            interested to find that the simple Freeglut / OpenGL demo
            programs I've tried on Windows also work on my WSL Ubuntu
            with the Windows generated jextract classes via X server. <br>
          </div>
          <div class="moz-cite-prefix"><br>
          </div>
          <div class="moz-cite-prefix">All I changed was remove the "-l
            opengl32 -l freeglut" parameters from Windows jextract run
            so that it did not inject the Windows loadLibrary calls into
            RuntimeHelper.java, and substitute equivalent code into the
            demo instead, like this<br>
          </div>
          <div class="moz-cite-prefix"><br>
          </div>
          <div class="moz-cite-prefix"> System.out.format("Initialise
            freeglut for os.name=%s%n", System.getProperty("os.name"));<br>
            final String[] libs =
            System.getProperty("os.name").startsWith("Windows")<br>
            ? new String[]{"opengl32", "freeglut"} : new
            String[]{"glut"};<br>
            for (String lib : libs) {<br>
            System.out.format("loadLibrary(\"%s\")%n", lib);<br>
            System.loadLibrary(lib);<br>
            }<br>
          </div>
          <div class="moz-cite-prefix"><br>
          </div>
          <div class="moz-cite-prefix">I guess I am lucky the APIs and
            struct used by the simple code sample are consistent.</div>
          <div class="moz-cite-prefix"><br>
          </div>
          <div class="moz-cite-prefix">Kind regards</div>
          <div class="moz-cite-prefix"><br>
          </div>
          <div class="moz-cite-prefix">Duncan<br>
          </div>
          <div class="moz-cite-prefix"><br>
          </div>
          <div class="moz-cite-prefix"><br>
          </div>
          <div class="moz-cite-prefix">On 20/12/2022 15:51, Maurizio
            Cimadamore wrote:<br>
          </div>
          <blockquote type="cite">
            <p>Hi Martin,<br>
              at the time of writing, jextract does not have a solution
              for this.</p>
            <p>I also believe that a general solution might not even
              exist - sometimes the bindings can vary quite wildly
              across different platforms, and there could be significant
              layout mismatches which would be hard to reconcile. For
              instance on Windows, C_LONG is a layout with type
              ValueLayout.OfInt, whereas on Linux x64 the type is
              ValueLayout.OfLong. On top of that, some subset of native
              functions might only be available on some platforms but
              not in others, etc.</p>
            <p>Considering all this, while some automated solution might
              be possible for the use case you have in mind, most surely
              it would fail to scale to the general case - so the
              general recommendation is to generate different bindings
              (one per platform) and then come up with some abstraction
              layer on top (which is sort of what you are trying to do).
              Another approach that might work would be to work at a
              lower level - and generate ad-hoc downcall method handles
              which automagically fix up mismatches that can arise
              across platforms (e.g. if a function is available in two
              platforms with a parameter mismatch int vs. long, adapt
              the int-accepting method handle to take a long, so that a
              uniform signature can be used). Note that jextract should
              expose the method handles it generates, so perhaps this
              adaptation can be done semi-automatically based on what
              comes out of jextract (and based on what the mismatches
              really are in your use case). <br>
            </p>
            <p>I know that e.g. the JavaDoesUSB [1] project has faced
              similar issues, so perhaps their authors might want to
              share some insights here.</p>
            <p>Cheers<br>
              Maurizio<br>
              <br>
              [1] - <a href="https://urldefense.com/v3/__https://github.com/manuelbl/JavaDoesUSB__;!!ACWV5N9M2RV99hQ!IRFSrMVNmEB7NAN0-PbWsghPrg_9SFMxZ3v0nzDrJZcSqdO-Y9DTVoFVczyfpWrqOP3OFqMkAYOsbgjePYhQH28frd0QFcnv1yT5eg$" class="moz-txt-link-freetext" rel="noreferrer nofollow
                noopener" target="_blank" moz-do-not-send="true">https://github.com/manuelbl/JavaDoesUSB</a><br>
            </p>
            <div class="moz-cite-prefix">On 20/12/2022 15:04, Martin
              Pernollet wrote:<br>
            </div>
            <blockquote type="cite">
              <div>Hi everyone,</div>
              <div><br>
              </div>
              <div>I am back on track with OpenGL binding with Panama!</div>
              <div><br>
              </div>
              <div>I have one code design / tooling question related to
                JExtract : is it possible to <b>generate a common
                  interface that would be implemented by all platform
                  specific binding</b> generated by JExtract since JDK
                19 or 20?</div>
              <div><br>
              </div>
              <div>Here's my use case in more detail : I've been advised
                to generate <b>different binding for different OS</b>
                (and maybe version). For OpenGL, this lead me to a
                glut_h binding for macOS, one for Windows and one for
                Linux.</div>
              <div><br>
              </div>
              <div>To let <b>the user/developer face a single entry
                  point</b>, I manually write a <a title="GL interface" href="https://urldefense.com/v3/__https://github.com/jzy3d/panama-gl/blob/feature/fbo/src/main/java/opengl/GL.java__;!!ACWV5N9M2RV99hQ!IRFSrMVNmEB7NAN0-PbWsghPrg_9SFMxZ3v0nzDrJZcSqdO-Y9DTVoFVczyfpWrqOP3OFqMkAYOsbgjePYhQH28frd0QFckal4DzzA$" rel="noreferrer nofollow noopener" target="_blank" moz-do-not-send="true">GL interface</a>. I then define
                a <a title="GL_macOS_10_15_3" href="https://urldefense.com/v3/__https://github.com/jzy3d/panama-gl/blob/feature/fbo/src/main/java/opengl/macos/GL_macOS_10_15_3.java__;!!ACWV5N9M2RV99hQ!IRFSrMVNmEB7NAN0-PbWsghPrg_9SFMxZ3v0nzDrJZcSqdO-Y9DTVoFVczyfpWrqOP3OFqMkAYOsbgjePYhQH28frd0QFck-yD4cHw$" rel="noreferrer nofollow noopener" target="_blank" moz-do-not-send="true">GL_macOS_10_15_3</a> class that
                wraps the binding (!). When I expand the prototype to
                Windows, I should copy paste this to GL_Windows_10 and
                modify the imports to reference the appropriate
                bindings. The goal is to write code like this</div>
              <div><br>
              </div>
              <div>GL gl = Platform.selectAmong(GL_macOS_10_15_3.class,
                GL_windows_10.class, ...)</div>
              <div>gl.glDoSomething()</div>
              <div><br>
              </div>
              <div>I don't think there would be another way to have java
                developer write <b>applications that ignore the target
                  hardware</b>. However my approach is stupid : time
                consuming and error prone because manual. A real life
                case may have 10 implementations and 1000 functions.</div>
              <div><br>
              </div>
              <div><b>Does JExtract provide a solution to this</b>?
                Should I create this tool by myself based on all
                generated bindings ? Would anyone <b>recommend
                  something smarter</b>?</div>
              <div><br>
              </div>
              <div>Regards,</div>
              <div><br>
              </div>
              <div>Martin </div>
              <div><br>
              </div>
              <div class="protonmail_signature_block"> </div>
            </blockquote>
          </blockquote>
          <p><br>
          </p>
        </blockquote>
        <br>
      </div>
    </blockquote>
  </body>
</html>