Are there plans to have an option for jextract to create an optimized binding?

[Maurizio Cimadamore]

On 10/03/2023 10:23, Christoph Läubrich wrote:
> 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!

I don't disagree - although, the main idea here is that you can simply 
filter the contents of the dump file using a "grep -v". In fact, in the 
long run, it might be better to have the exact argument file you want to 
use to run jextract checked into your repo. We do this for jextract 
ourselves:

https://github.com/openjdk/jextract/blob/master/updateclang/clang.symbols

As people will use jextract more, I think we will get a clearer idea of 
which "idioms" are common enough to be lifted to proper command line 
options.

Maurizio


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