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, like the bindings to graphic pipelines, then you won't want to re-run the task until you actually change the native side yourself.
On Sun, Nov 17, 2024 at 6:44 PM Thiago Milczarek Sayão < thiago.sa...@gmail.com> wrote: > 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 <nlis...@gmail.com> > escreveu: > >> 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 the PR. Not sure what package arrangement is suitable. >> >> On Sun, Nov 17, 2024 at 4:29 PM Thiago Milczarek Sayão < >> thiago.sa...@gmail.com> wrote: >> >>> Hi, >>> >>> Are there any plans to make a default way to use jextract (or any other >>> way to use ffm) on the gradle build system? >>> >>> -- Thiago >>> >>
