How to tell jextract to use different lib name for the same binding?

[Davide Perini]

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>