Are there plans to have an option for jextract to create an optimized binding?
Christoph Läubrich
laeubi at laeubi-soft.de
Fri Mar 10 10:23:19 UTC 2023
Hi Maurizio,
I have now played around with that option and the filtering works well!
I just found one possible way to built into jextract directly that could
be quite simple:
While cleaning up the generated file I found my self very often simply
stripping away anything "not from xyz.h", so I think an option like
--limit header1.h,header2.h would reduce the manual work here!
of course one can write a shellscript for that as well, but as each line
already has a comment
# header: /usr/include/myheader.h
it seems quite easy to implement that directly at jextract level!
Am 09.03.23 um 12:51 schrieb Maurizio Cimadamore:
>
> On 09/03/2023 11:46, Christoph Läubrich wrote:
>> Hi Maurizio,,
>>
>> that already looks promising!
>>
>> Would be cool if jextract could even automate this, so it finds the
>> symbols from existing class files?
>>
>> I can think about the following:
>>
>> 1) I generate all bindings
>> 2) I have my code and test finished, and run jextract again, passing
>> it my jar file
>> 3) I get a binding with only things required.
>>
>> because for a complex binding I can think its quite hard to find out
>> what I don't care about.
>
> I think this is not impossible - that said, I think the jextract tool
> should provide primitive knobs, which are expressive enough to let
> developers do what they want. For instance, the jar-analyzer tool you
> describe could also be built on top of jextract.
>
> Ideally, I think it would be nice if, one day, IDEs had some kind of
> integration for this: the extraction process is interactive, and I think
> that jextract would benefit greatly from some kind of UI. There's only
> so much we can capture via simple command line options.
>
> Maurizio
>
>
>>
>> Am 09.03.23 um 12:18 schrieb Maurizio Cimadamore:
>>> Hi Christoph,
>>> note that jextract already supports a filtering mechanism. The basic
>>> usage is described here:
>>>
>>> https://urldefense.com/v3/__https://github.com/openjdk/jextract*filtering-symbols__;Iw!!ACWV5N9M2RV99hQ!NU_jGOsWk3eJe3kZW2eDc6W9aq6KhmLkOhY78Z7IH6iyWhIw6zT4bTtp_duQ_061rh7ybJcHWGE-vbehtkYce9DViH2B$
>>> That is:
>>>
>>> 1. you can run jextract in a way so that it dumps all the symbols it
>>> could find during its execution (--dump-includes=<filename>)
>>> 2. you can then edit the generated file, and drop all the symbols
>>> your application doesn't care about
>>> 3. you can pass the edited file back to jextract, as an "argfile"
>>> e.g. "@<filename>"
>>>
>>> This will only generate bindings for the things you care about.
>>>
>>> Hope this helps
>>>
>>> Maurizio
>>>
>>>
>>> On 09/03/2023 11:05, Christoph Läubrich wrote:
>>>> Hi Panama Devs,
>>>>
>>>> I hope the mailinglist is the right place for such
>>>> questions/discussions/ideas, as the github repository has not
>>>> enabled Github-Discussions.
>>>>
>>>> jextract is doing a great work, but for some libs it produces a very
>>>> very large result ( ~ 3000 files or more), I therefore wonder if it
>>>> would be possible to have jextract passing some code (e.g. a jar)
>>>> using the binding and then it generates an optimized binding that
>>>> only contains the functions/constants that are actually used in the
>>>> java code?
>>>>
>>>> thank in advance,
>>>> Christoph
More information about the panama-dev
mailing list