<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>