I was thinking about including a generation task as part of the build.
But you're right, I can make a simpler task that generates it by running
jextract only on demand rather than being part of the build.
Em dom., 17 de nov. de 2024 às 13:18, Nir Lisker
escreveu:
> jextract is something y
The latter (have the bindings generated at build time) is more in line with
other parts of OpenJFX (e.g. decora).
Also, the generated files can be large, and depend on what version of
jextract one is using.
I think it's better not to have them in the src section of the code, but to
generate them at
I would have a system lib that would be compatible forever (theoretically)
and some C code,
but I just want to bind specific functions, structs, typedefs, vars and
constants (it's a big jextract command)
So in the need of new functions from C to java, some might need to
re-generate the bindings an
The question is: what are you binding to? If it's a library on the OS that
gets updated from time to time and JavaFX relies on it being there (not
bundled), then the generated bindings in a task could change and break
compilation if the Java code wasn't changed. If it's a library created by
JavaFX,
jextract is something you run once to produce the FFM bindings that you
then add to your code base, there's no need to make it part of the build
(although I guess you can). I would think that If you're creating a PR that
needs FFM, use jextract to produce the java files and submit them as part
of t
