RFR: Streamline gradle task dependencies [v2]

[Jorn Vernee]

On Wed, 7 Feb 2024 15:10:14 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> The main point of this PR is to remove the `verify` task as a dependency of the `createRuntimeImageForTest` task. Sometimes you have a broken jextract that you want to debug, which requires a test image, but the `verify` task is failing, meaning the `createRuntimeImageForTest` can not run. Removing `verify` as a dependency allows the test image to be built and debugged
>> 
>> ~I've added both the `verify` and `jtreg` tasks as dependencies of `test`, so now the `test` task can be used to run all tests.~ (P.S. this added an invisible dependency of the `clean` task on the `jtreg` task, which makes the GHA build fail. I've remove this again)
>> 
>> I also took a look at the dependency setups of the other tasks. `copyLibClang` was depending on `jar` which is not required. I added the `jar` dependency to `createJextractJmod` instead which actually uses the jar file. This allows `copyLibClang` to run in parallel with other tasks. I had to slightly change it though: since it was using: `into("$buildDir")`, the entire build dir was treated as an output of the copy task, and this made gradle throw up several warnings because other tasks didn't have `copyLibClang` as a dependency. I've changed `copyLibClang` to copy the files into a build dir subdirectory instead, which is used exclusively as an output of the copy task.
>> 
>> Lastly, I removed some redundant inputs from tasks. A task is rebuilt if a dependency ran and the outputs changed, so there is no need to set the jar file as an explicit input. The images will be recreated if the jmod file changed, which will be recreated if the jar file changed. However, in this new setup, if the jar file was rebuilt, but the jmod didn't change as a result, we don't need to rebuild the images.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   don't add test task deps

Yes, `verify` has no dependency. It can be used as a quick smoke test to check whether a build of jextract succeeded.

I don't think it's useful to add it as a dependency of `jtreg`, since that task already does much more comprehensive testing. Notice also that `verify` depends on the non-test runtime image of jextract, while `jtreg` depends on the test image. Adding `verify` as a dependency of `jtreg` would mean you'd be required to build both images to run the tests.

We could possibly add `verify` as a dependency of `build` though

-------------

PR Comment: https://git.openjdk.org/jextract/pull/200#issuecomment-1932604102