Tooling question: Jextract as a library for programmatic usage

[Tamara Cook]

Hi Maurizio,

Very interesting, thanks for your insights.

Indeed, packaging native deps is not trivial at all, but maybe I would look into stuff like JavaFX where natives are included. SWT, the Eclipse UI toolkit, has platform-specific maven artifacts on Maven Central.

Gradle module metadata can describe publications with multiple variants using attributes. Maybe variant-aware sharing points to a promising direction:
https://docs.gradle.org/current/userguide/cross_project_publications.html#sec:variant-aware-sharing

Concerning your last question: The only difference is convenience, build automation and zero-configuration experience. ;-) The result should be the same, but for a project using Gradle, contributors should not need to care about build requirements, except for JVM of course. All they should need to get started is clone and run ./gradlew build. Even Gradle itself doesn’t have to be pre-installed but gets downloaded via wrapper. My Jextract Gradle plugin downloads and installs Jextract into a certain directory for being used in build steps, so users don’t stumble upon installing it manually, set PATH variable etc. If such plugins could use Jextract directly from a Maven publication as library, integration would be more robust and elegant than downloading and running a CLI app. You could try the variant-aware approach for targeting different platforms, or be more simplistic, having different Maven coordinates per platform like SWT.

My impression is that there are different perspectives on how configuring and maintaining a build is thought about, and this results in some disconnect (lacking support for jlink and jpackage). Modeling a Gradle build feels more like working with a declarative reactive framework than scripting sequential build commands. Running a cli tool feels natural for the imperative scripting approach, but it feels like a step backward for the declarative reactive approach where a programmatic API would feel more straight-forward. Just gut feelings from a coding psychologist. ;-)

Greetings and have a nice day
Tamara

> Am 08.10.2024 um 15:27 schrieb Maurizio Cimadamore <maurizio.cimadamore at oracle.com>:
> 
> 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