From jorn.vernee at oracle.com  Thu Nov  7 14:32:30 2024
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Thu, 7 Nov 2024 15:32:30 +0100
Subject: New jextract build released (22-jextract+6-47)
Message-ID: <99ee8782-5529-44bb-8d2d-2a7d2f8bbbda@oracle.com>

Hey all,

We just published a new jextract build. We've added a new build for the 
Linux/AArch64 platform. Besides that, these are the other user-facing 
changes that are worth highlighting:

7903782: clang warnings and diagnostics below warning level should be 
logged as well [1]
7903779: unify logger messages to show position whenever possible [2]
7903776: jextract generates uncompilable code when C identifier with the 
name from "java.lang" classes is used [3]
7903777: jextract layout for enum with big constant values is wrong [4]
7903755: multi header support and special syntax for header file [5]

I want to call special attention to the last entry in this list: It is 
no longer required to specify the full path of the header file you want 
to extract. The header file just has to be findable in one of the 
locations specified through the -I options. This should simplify the 
command line somewhat. It is also possible to use the form <foo.h> to 
pass a file to jextract (given sufficient shell quoting [6]). Doing this 
mimics the behavior of a header file included like #include <foo.h> 
within a C source file, which looks in a standard list of system 
directories for the included header file. Though the exact directories 
that are searched is platform dependent, it's possible to show the 
header file search directories by using a compile_flags.txt [7] file 
with the --verbose option. For example, by default, on my Windows 
machine, this prints something like:

#include "..." search starts here:
#include <...> search starts here:
 ?C:\<path to>\jextract\runtime\conf\jextract
 ?C:\<path to>\<current directory>
 ?C:\Program Files\Microsoft Visual 
Studio\2022\Community\VC\Tools\MSVC\14.39.33519\include
 ?C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\ucrt
 ?C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\shared
 ?C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\um
 ?C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\winrt
End of search list.

This latest version of jextract still targets Java 22 as a baseline, but 
the generated bindings will work on Java 23 as well. If you find any 
issues with the new build, please report them back to this mailing list 
(jextract-dev at openjdk.org).

Thanks,
Jorn

[1]:?https://bugs.openjdk.org/browse/CODETOOLS-7903782
[2]: https://bugs.openjdk.org/browse/CODETOOLS-7903779
[3]: https://bugs.openjdk.org/browse/CODETOOLS-7903776
[4]: https://bugs.openjdk.org/browse/CODETOOLS-7903777
[5]: https://bugs.openjdk.org/browse/CODETOOLS-7903755
[6]: '<foo.h>' in most shells, ^^<foo.h^^> in cmd.exe
[7]: 
https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md#additional-clang-options


From jorn.vernee at oracle.com  Thu Nov  7 14:43:57 2024
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Thu, 7 Nov 2024 15:43:57 +0100
Subject: New jextract build released (22-jextract+6-47)
In-Reply-To: <99ee8782-5529-44bb-8d2d-2a7d2f8bbbda@oracle.com>
References: <99ee8782-5529-44bb-8d2d-2a7d2f8bbbda@oracle.com>
Message-ID: <eb925dbc-0696-4ae5-ab9b-03ab387cc9bd@oracle.com>

Totally forgot to mention this, but as usual, the new builds can be 
found at: https://jdk.java.net/jextract/

Jorn

On 7-11-2024 15:32, Jorn Vernee wrote:
> Hey all,
>
> We just published a new jextract build. We've added a new build for 
> the Linux/AArch64 platform. Besides that, these are the other 
> user-facing changes that are worth highlighting:
>
> 7903782: clang warnings and diagnostics below warning level should be 
> logged as well [1]
> 7903779: unify logger messages to show position whenever possible [2]
> 7903776: jextract generates uncompilable code when C identifier with 
> the name from "java.lang" classes is used [3]
> 7903777: jextract layout for enum with big constant values is wrong [4]
> 7903755: multi header support and special syntax for header file [5]
>
> I want to call special attention to the last entry in this list: It is 
> no longer required to specify the full path of the header file you 
> want to extract. The header file just has to be findable in one of the 
> locations specified through the -I options. This should simplify the 
> command line somewhat. It is also possible to use the form <foo.h> to 
> pass a file to jextract (given sufficient shell quoting [6]). Doing 
> this mimics the behavior of a header file included like #include 
> <foo.h> within a C source file, which looks in a standard list of 
> system directories for the included header file. Though the exact 
> directories that are searched is platform dependent, it's possible to 
> show the header file search directories by using a compile_flags.txt 
> [7] file with the --verbose option. For example, by default, on my 
> Windows machine, this prints something like:
>
> #include "..." search starts here:
> #include <...> search starts here:
> ?C:\<path to>\jextract\runtime\conf\jextract
> ?C:\<path to>\<current directory>
> ?C:\Program Files\Microsoft Visual 
> Studio\2022\Community\VC\Tools\MSVC\14.39.33519\include
> ?C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\ucrt
> ?C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\shared
> ?C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\um
> ?C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\winrt
> End of search list.
>
> This latest version of jextract still targets Java 22 as a baseline, 
> but the generated bindings will work on Java 23 as well. If you find 
> any issues with the new build, please report them back to this mailing 
> list (jextract-dev at openjdk.org).
>
> Thanks,
> Jorn
>
> [1]:?https://bugs.openjdk.org/browse/CODETOOLS-7903782
> [2]: https://bugs.openjdk.org/browse/CODETOOLS-7903779
> [3]: https://bugs.openjdk.org/browse/CODETOOLS-7903776
> [4]: https://bugs.openjdk.org/browse/CODETOOLS-7903777
> [5]: https://bugs.openjdk.org/browse/CODETOOLS-7903755
> [6]: '<foo.h>' in most shells, ^^<foo.h^^> in cmd.exe
> [7]: 
> https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md#additional-clang-options
>

From wo6980 at gmail.com  Fri Nov  8 11:09:06 2024
From: wo6980 at gmail.com (Oliver Weiler)
Date: Fri, 8 Nov 2024 12:09:06 +0100
Subject: New jextract build released (22-jextract+6-47)
In-Reply-To: <eb925dbc-0696-4ae5-ab9b-03ab387cc9bd@oracle.com>
References: <99ee8782-5529-44bb-8d2d-2a7d2f8bbbda@oracle.com>
 <eb925dbc-0696-4ae5-ab9b-03ab387cc9bd@oracle.com>
Message-ID: <CAKse9ygz94heHL9PBEGv=NS9TXir4C7d7hBEhxYOy0vAb_ahDA@mail.gmail.com>

And it's already on SDKMAN!

sdk install jextract

Am Do., 7. Nov. 2024 um 15:44 Uhr schrieb Jorn Vernee <
jorn.vernee at oracle.com>:

> Totally forgot to mention this, but as usual, the new builds can be
> found at: https://jdk.java.net/jextract/
>
> Jorn
>
> On 7-11-2024 15:32, Jorn Vernee wrote:
> > Hey all,
> >
> > We just published a new jextract build. We've added a new build for
> > the Linux/AArch64 platform. Besides that, these are the other
> > user-facing changes that are worth highlighting:
> >
> > 7903782: clang warnings and diagnostics below warning level should be
> > logged as well [1]
> > 7903779: unify logger messages to show position whenever possible [2]
> > 7903776: jextract generates uncompilable code when C identifier with
> > the name from "java.lang" classes is used [3]
> > 7903777: jextract layout for enum with big constant values is wrong [4]
> > 7903755: multi header support and special syntax for header file [5]
> >
> > I want to call special attention to the last entry in this list: It is
> > no longer required to specify the full path of the header file you
> > want to extract. The header file just has to be findable in one of the
> > locations specified through the -I options. This should simplify the
> > command line somewhat. It is also possible to use the form <foo.h> to
> > pass a file to jextract (given sufficient shell quoting [6]). Doing
> > this mimics the behavior of a header file included like #include
> > <foo.h> within a C source file, which looks in a standard list of
> > system directories for the included header file. Though the exact
> > directories that are searched is platform dependent, it's possible to
> > show the header file search directories by using a compile_flags.txt
> > [7] file with the --verbose option. For example, by default, on my
> > Windows machine, this prints something like:
> >
> > #include "..." search starts here:
> > #include <...> search starts here:
> >  C:\<path to>\jextract\runtime\conf\jextract
> >  C:\<path to>\<current directory>
> >  C:\Program Files\Microsoft Visual
> > Studio\2022\Community\VC\Tools\MSVC\14.39.33519\include
> >  C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\ucrt
> >  C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\shared
> >  C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\um
> >  C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\winrt
> > End of search list.
> >
> > This latest version of jextract still targets Java 22 as a baseline,
> > but the generated bindings will work on Java 23 as well. If you find
> > any issues with the new build, please report them back to this mailing
> > list (jextract-dev at openjdk.org).
> >
> > Thanks,
> > Jorn
> >
> > [1]: https://bugs.openjdk.org/browse/CODETOOLS-7903782
> > [2]: https://bugs.openjdk.org/browse/CODETOOLS-7903779
> > [3]: https://bugs.openjdk.org/browse/CODETOOLS-7903776
> > [4]: https://bugs.openjdk.org/browse/CODETOOLS-7903777
> > [5]: https://bugs.openjdk.org/browse/CODETOOLS-7903755
> > [6]: '<foo.h>' in most shells, ^^<foo.h^^> in cmd.exe
> > [7]:
> >
> https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md#additional-clang-options
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20241108/3142df47/attachment.htm>

From maurizio.cimadamore at oracle.com  Wed Nov 13 10:50:53 2024
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 13 Nov 2024 10:50:53 +0000
Subject: How to tell jextract to use different lib name for the same
 binding?
In-Reply-To: <eef1991964188aeb6d7ae2cb40bcac72@dpsoftware.org>
References: <eef1991964188aeb6d7ae2cb40bcac72@dpsoftware.org>
Message-ID: <255c588b-6256-4cb1-b99b-fd6b2f56cdd6@oracle.com>

Hi,
thanks for the feedback, and the positive comments :-)

I see what you mean - you basically have two possible names for the 
library, and either one or the other should "match".

Now, the jextract code could be updated a little. For instance, jextract 
could be a bit smarter when creating the library lookup: if an exception 
is thrown, some kind of "empty lookup" could be used. This would avoid 
exceptions being thrown.

This is doable -- but the question then becomes: what if a user really 
expects a library to be there? In that case, the exception would be 
"swallowed" only to pop up later, e.g. when the first downcall is 
created (at which point the bindings will fail because no symbol for the 
downcall could be found -- given the library has not been loaded at all).

So, doing a change like the one you suggest amounts at attempting to 
read the user mind (and all tools -- jextract included -- are 
notoriously bad at that :-) ). Now, it might be that the "exception 
swallowing" behavior I described above is more generally useful than 
what we do now, but with things like these I'm always afraid that what's 
best for some developers might not be best for others. So... we need 
more feedback from all of you to understand whether such a change would 
be perceived as beneficial.

A similar issue was also discussed here:

https://mail.openjdk.org/pipermail/jextract-dev/2024-September/001949.html

Note also that, longer term (as mentioned in that discussion) we have 
plans to allow custom SymbolLookups to be plugged in by users, so that 
jextract can get away with "less mind reading".

Cheers
Maurizio

On 13/11/2024 10:35, Davide Perini wrote:
>
> Hi all,
> I'm starting to use jextract to workaround some issues I found in AWT.
> AWT uses 20+ years old APIs for notifications and tray icons and it 
> doesn't work well in recent Linux distros and on Windows 11 24H2.
>
> I must say that foreign memory API is a massive improvement to the 
> Java ecosystem, wow.
> I created a binding for the tray icon and for the notification API in 
> minutes, this is awesome.
>
> To create my bindings I start with jextract with something like this:
> jextract \
> -l ayatana-appindicator3 \
> -l appindicator3 \
> ....
> /usr/include/libayatana-appindicator3-0.1/libayatana-appindicator/app-indicator.h
>
>
> With this command I would tell to jextract to search for
> ayatana-appindicator3
> or
> appindicator3
>
> but when I use the binding it throws an exception if one of the two 
> libs are not present.
>
>
> Libs uses the same interfaces and I don't need two bindings for these 
> two libraries.
>
> Is it possible to tell to jextract to create a binding that searches 
> for "multiple lib name" and don't throw and error in the event that 
> one lib is found?
>
> Thanks
> Davide
>

From jr at qsm.co.il  Sat Nov 16 12:42:25 2024
From: jr at qsm.co.il (Jonathan Rosenne)
Date: Sat, 16 Nov 2024 12:42:25 +0000
Subject: warning: 'dllexport' attribute only applies to ...
Message-ID: <PAVPR10MB67891E1E2923D59422D930C584252@PAVPR10MB6789.EURPRD10.PROD.OUTLOOK.COM>

With the new version 22-jextract+6-47 I am receiving the following warning:

"warning: 'dllexport' attribute only applies to functions, variables, classes, and Objective-C interfaces"

The functions are defined indirectly (by means of a macro) for as __declspec(dllexport)

The output is identical to that produced by the previous version.

Best Regards,

Jonathan Rosenne

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20241116/bbac31fa/attachment.htm>

From maurizio.cimadamore at oracle.com  Mon Nov 18 09:59:35 2024
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 18 Nov 2024 09:59:35 +0000
Subject: warning: 'dllexport' attribute only applies to ...
In-Reply-To: <PAVPR10MB67891E1E2923D59422D930C584252@PAVPR10MB6789.EURPRD10.PROD.OUTLOOK.COM>
References: <PAVPR10MB67891E1E2923D59422D930C584252@PAVPR10MB6789.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <58f461cb-e702-413c-85b3-edee4e91e7e4@oracle.com>

I believe this is caused by the fact that jextract now propagates all 
diagnostics from the underlying clang parsing:

https://git.openjdk.org/jextract/pull/255

I suppose that change is what is generating the extra "noise", although 
in this case it's possible that there's indeed a real "issue" in the 
underlying header file, where __declspec is applied to some incorrect 
program element.

I guess in the future it might be possible to add a knob to select the 
level of "noise" coming from clang. In some cases it might be useful to 
see some of these messges, but I can also imagine cases where (e.g. 
during a build of something that's known to work) perhaps having too 
many messages from the underlying clang compiler might not be desirable. 
Something simple like verbose:all/info/warn/error.

Cheers
Maurizio

On 16/11/2024 12:42, Jonathan Rosenne wrote:
>
> With the new version 22-jextract+6-47 I am receiving the following 
> warning:
>
> "warning: 'dllexport' attribute only applies to functions, variables, 
> classes, and Objective-C interfaces"
>
> The functions are defined indirectly (by means of a macro) for as 
> __declspec(dllexport)
>
> The output is identical to that produced by the previous version.
>
> Best Regards,
>
> Jonathan Rosenne
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20241118/36992f7f/attachment-0001.htm>

From maurizio.cimadamore at oracle.com  Mon Nov 25 11:51:29 2024
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 25 Nov 2024 11:51:29 +0000
Subject: Flathub is not accepting my app that uses Foreign Functions and
 Memory API
In-Reply-To: <bd1a4492-9b5e-4c20-b591-76ebca5991dc@dpsoftware.org>
References: <be652e9c-fdf3-4d02-a97d-0f719e1cf1bd@dpsoftware.org>
 <bd1a4492-9b5e-4c20-b591-76ebca5991dc@dpsoftware.org>
Message-ID: <9194d2c5-2cd4-4c8e-947d-6253f0484dc3@oracle.com>

Phew. Another possibility, assuming the library dependency on libnotify 
can be found using dynamic linker, would be to use 
|SymbolLookup.libraryLookup("libnotify.so.X")| (where X is the version 
number you need). You can find the list of libraries available in your 
system typically by running |ldconfig -p| and then grepping for whatever 
you are looking for.

If the library is already installed in the Flathub runtime, there might 
be no need to have the dependency in your package?

Maurizio

On 24/11/2024 01:01, Davide Perini wrote:

> It was my fault, the binding generated with jextract was not using the 
> right path for the flatpak runtime.
>
> I fixed it with a static initialization of the lib on the correct path 
> as discussed days ago for another issue.
>
> Problem solved.
>
> Thanks
>
> On 23/11/24 12:52, Davide Perini wrote:
>> Hi there,
>> I wrote a small app that uses Foreign Functions and Memory API to 
>> show some toasts on Linux
>> using libnotify.
>>
>> The bindings is available here:
>> https://github.com/sblantipodi/firefly_luciferin/tree/dx12_pipeline/src/main/java/org/dpsoftware/gui/bindings/notify 
>>
>>
>> Flathub maintainers are not accepting my app because they say that 
>> libnotify is already included in their runtime and that the libnotify 
>> is "build only".
>> I bundled the builded .so file in my app and it works well,
>> but they don't like that I need a .so file for this and they are not 
>> accepting my app.
>>
>> Is there something I'm not understanding?
>>
>> https://github.com/flathub/flathub/pull/5874#discussion_r1854943995
>>
>> Is there a way to do what I'm doing better?
>>
>> Thanks
>> Davide
>>
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20241125/93447dec/attachment.htm>

From perini.davide at dpsoftware.org  Sat Nov 23 11:52:31 2024
From: perini.davide at dpsoftware.org (Davide Perini)
Date: Sat, 23 Nov 2024 12:52:31 +0100
Subject: Flathub is not accepting my app that uses Foreign Functions and
 Memory API
Message-ID: <be652e9c-fdf3-4d02-a97d-0f719e1cf1bd@dpsoftware.org>

Hi there,
I wrote a small app that uses Foreign Functions and Memory API to show 
some toasts on Linux
using libnotify.

The bindings is available here:
https://github.com/sblantipodi/firefly_luciferin/tree/dx12_pipeline/src/main/java/org/dpsoftware/gui/bindings/notify

Flathub maintainers are not accepting my app because they say that 
libnotify is already included in their runtime and that the libnotify is 
"build only".
I bundled the builded .so file in my app and it works well,
but they don't like that I need a .so file for this and they are not 
accepting my app.

Is there something I'm not understanding?

https://github.com/flathub/flathub/pull/5874#discussion_r1854943995

Is there a way to do what I'm doing better?

Thanks
Davide


From perini.davide at dpsoftware.org  Sun Nov 24 01:01:36 2024
From: perini.davide at dpsoftware.org (Davide Perini)
Date: Sun, 24 Nov 2024 02:01:36 +0100
Subject: Flathub is not accepting my app that uses Foreign Functions and
 Memory API
In-Reply-To: <be652e9c-fdf3-4d02-a97d-0f719e1cf1bd@dpsoftware.org>
References: <be652e9c-fdf3-4d02-a97d-0f719e1cf1bd@dpsoftware.org>
Message-ID: <bd1a4492-9b5e-4c20-b591-76ebca5991dc@dpsoftware.org>

It was my fault, the binding generated with jextract was not using the 
right path for the flatpak runtime.

I fixed it with a static initialization of the lib on the correct path 
as discussed days ago for another issue.

Problem solved.

Thanks

On 23/11/24 12:52, Davide Perini wrote:
> Hi there,
> I wrote a small app that uses Foreign Functions and Memory API to show 
> some toasts on Linux
> using libnotify.
>
> The bindings is available here:
> https://github.com/sblantipodi/firefly_luciferin/tree/dx12_pipeline/src/main/java/org/dpsoftware/gui/bindings/notify 
>
>
> Flathub maintainers are not accepting my app because they say that 
> libnotify is already included in their runtime and that the libnotify 
> is "build only".
> I bundled the builded .so file in my app and it works well,
> but they don't like that I need a .so file for this and they are not 
> accepting my app.
>
> Is there something I'm not understanding?
>
> https://github.com/flathub/flathub/pull/5874#discussion_r1854943995
>
> Is there a way to do what I'm doing better?
>
> Thanks
> Davide
>

From perini.davide at dpsoftware.org  Wed Nov 13 13:33:26 2024
From: perini.davide at dpsoftware.org (Davide Perini)
Date: Wed, 13 Nov 2024 14:33:26 +0100
Subject: How to tell jextract to use different lib name for the same
 binding?
In-Reply-To: <255c588b-6256-4cb1-b99b-fd6b2f56cdd6@oracle.com>
References: <eef1991964188aeb6d7ae2cb40bcac72@dpsoftware.org>
 <255c588b-6256-4cb1-b99b-fd6b2f56cdd6@oracle.com>
Message-ID: <68f1ae7cf8587659eb8bd88b6c7ad05f@dpsoftware.org>



Hi Maurizio,
thanks for the answer, I really appreciate it.

I agree that "mind reading" is not possible this days but as you 
mentioned, a custom SymbolLookups would be great.

In the mean time to make it work I removed the --library param when 
using jextract and
I created a static {} block in my class that manually loads the libs.

https://github.com/sblantipodi/firefly_luciferin/blob/271bf8ddf28ae32454efa9bddc2edd30a4556cff/src/main/java/org/dpsoftware/gui/bindings/appindicator/LibAppIndicator.java#L137

Thanks again for the answer.

Ciao
Davide

On 2024-11-13 11:50, Maurizio Cimadamore wrote:

> Hi,
> thanks for the feedback, and the positive comments :-)
> 
> I see what you mean - you basically have two possible names for the 
> library, and either one or the other should "match".
> 
> Now, the jextract code could be updated a little. For instance, 
> jextract could be a bit smarter when creating the library lookup: if an 
> exception is thrown, some kind of "empty lookup" could be used. This 
> would avoid exceptions being thrown.
> 
> This is doable -- but the question then becomes: what if a user really 
> expects a library to be there? In that case, the exception would be 
> "swallowed" only to pop up later, e.g. when the first downcall is 
> created (at which point the bindings will fail because no symbol for 
> the downcall could be found -- given the library has not been loaded at 
> all).
> 
> So, doing a change like the one you suggest amounts at attempting to 
> read the user mind (and all tools -- jextract included -- are 
> notoriously bad at that :-) ). Now, it might be that the "exception 
> swallowing" behavior I described above is more generally useful than 
> what we do now, but with things like these I'm always afraid that 
> what's best for some developers might not be best for others. So... we 
> need more feedback from all of you to understand whether such a change 
> would be perceived as beneficial.
> 
> A similar issue was also discussed here:
> 
> https://mail.openjdk.org/pipermail/jextract-dev/2024-September/001949.html
> 
> Note also that, longer term (as mentioned in that discussion) we have 
> plans to allow custom SymbolLookups to be plugged in by users, so that 
> jextract can get away with "less mind reading".
> 
> Cheers
> Maurizio
> 
> On 13/11/2024 10:35, Davide Perini wrote:
> 
>> Hi all,
>> I'm starting to use jextract to workaround some issues I found in AWT.
>> AWT uses 20+ years old APIs for notifications and tray icons and it 
>> doesn't work well in recent Linux distros and on Windows 11 24H2.
>> 
>> I must say that foreign memory API is a massive improvement to the 
>> Java ecosystem, wow.
>> I created a binding for the tray icon and for the notification API in 
>> minutes, this is awesome.
>> 
>> To create my bindings I start with jextract with something like this:
>> jextract \
>> -l ayatana-appindicator3 \
>> -l appindicator3 \
>> ....
>> /usr/include/libayatana-appindicator3-0.1/libayatana-appindicator/app-indicator.h
>> 
>> With this command I would tell to jextract to search for
>> ayatana-appindicator3
>> or
>> appindicator3
>> 
>> but when I use the binding it throws an exception if one of the two 
>> libs are not present.
>> 
>> Libs uses the same interfaces and I don't need two bindings for these 
>> two libraries.
>> 
>> Is it possible to tell to jextract to create a binding that searches 
>> for "multiple lib name" and don't throw and error in the event that 
>> one lib is found?
>> 
>> Thanks
>> Davide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20241113/435dfb9e/attachment.htm>