Maybe have jextract output binding information instead of binding code via a command-line flag?

[Maurizio Cimadamore]

On 03/09/2019 11:15, Mark Hammons wrote:
> Hi All,
>
> I've been thinking about this since before when I was creating scala 
> bindings to a native library using panama's foreign interface. Would 
> it be possible for jextract to generate a set of binding information 
> (not classfiles or a jar, but a text, xml, or json file) that could be 
> parsed by languages like scala/clojure/etc, and used to generate their 
> own bindings? There are some concepts in scala 3 I would like to 
> combine with panama's foreign interface, but doing so requires 
> manually writing the bindings. With a textual representation of the 
> library info generated by jextract, I might be able to write some 
> scala macros that produce scala 3 bindings using panama's foreign 
> interface.

Short answer: yes and no (with a final twist) :-)

Full answer (which you might like or might not like): we are currently 
in a state where jextract is a relatively simple tool - you pass it an 
header, some options and it will spit a jarfile with some classes. That 
said, we have started to see some cracks in the ceilings - for instance 
the amount of options required for filtering headers seem to never be 
enough, some people would prefer jextract to output jmod, rather than 
jars - or something else (like in your case); lastly, some things that 
jextract needs to do require user intervention (e.g. function-like 
macros, C++ templates, civilization of bindings - such as exposing a 
Pointer<Byte> as a plain String).

All this seem to point to a model where the jextract tool is more 
open-ended, and allows users to inspect the internal representation it 
has with respect to the parsed C/C++ headers and, if they wish to do so, 
build plugins which tell jextract to do additional tasks, such as emit 
additional headers, or generate non-custom output on the side.

While we're not 100% sure of what the extension points will be - and how 
the user will be able to interact with them, all I can say at this point 
is that we're thinking about this, and see how this story would fit in 
the Panama picture.

In the interim (here's the twist), Sundar reminds me that there's an 
option in jextract which allows jextract to dump the generated sources 
"--src-dump-dir". With this and some parsing magic you might be able to 
derive the representation you want?

Cheers
Maurizio

>
> ~Mark
>