Tooling question: Jextract as a library for programmatic usage

[Maurizio Cimadamore]

Hi Tamara,
you raise a very good question.

The topic of whether jextract should be distributed as some kind of 
library has indeed been explored in the past. This is a bit challenging, 
as the jextract liibrary has a native library dependency (libclang) 
which makes it hard to distribute.

The jextract application comes with its own jextract jmod file (which 
includes the native library dependency), but, sadly, existing build 
tools cannot do much with it as they don't really integrate well with 
tools such as jlink.

To go back to your use case: in what way is generating bindings as an 
intermediate build step different from, say, generating bindings and 
making them available in the source set? Isn't it "just" matter of 
configuring jextract to dump its output source files in some directory 
in some build folder, and then add that folder to the list of the source 
trees?

Cheers
Maurizio

[1] - https://github.com/andreblanke/jextract-maven-plugin
[2] - https://github.com/krakowski/gradle-jextract

On 08/10/2024 14:05, Tamara Cook wrote:
> Hi,
>
> Let’s assume that running Jextract can be seen as a step in a complete build process, similar to other code generators e.g. ANTLR, ProtoBuf and alike. In this scenario, the bindings are not checked into source control, they’re build intermediates. This differs a bit from the more traditional approach of manually running Jextract once and committing the bindings.
>
> For the first approach, build tools have to integrate with Jextract. I was wondering if it would be realistic to have Jextract also packaged as a Java library for programmatic usage, so build tools or their plugins could use it as implementation dependency.
>
> Thanks and greetings
> Tamara