jextract standalone repository

[Maurizio Cimadamore]

Hi Daniel,
thanks for the feedback.

We're more than happy to accept contributions on this. I'd prefer to 
start with #3 - I think #1 seems to do its own magic to fetch a matching 
openjdk build (but w/o using one of those available in e.g. 
https://jdk.java.net/18/).

Thanks
Maurizio

On 26/03/2022 17:56, Daniel Jarabek wrote:
> Hi,
>
> I noticed you are using Gradle as a build tool for jextract. I took a 
> look at your build.gradle file and noticed a few things that could be 
> improved. I'm by no means a Gradle expert, but I hope my advice is 
> still helpful.
>
> 1. Use Gradle JVM toolchains
> Gradle JVM toolchains let you use JDKs other than the JDK Gradle is 
> running on. This would eliminate the need for the jdk18_home property. 
> Gradle automatically scans for JDKs matching the requirements in known 
> paths as well as user specified locations. Unfortunately, the moditect 
> plugin uses java.home to locate tools, however you can still manually 
> override this property with the location from the toolchain. The 
> jpackage plugin handles toolchains correctly. You can learn more about 
> Gradle toolchains here: 
> https://docs.gradle.org/current/userguide/toolchains.html
>
> 2. Use a more "gradle-like" approach
> This is a little bit harder to do. Gradle has advanced features 
> relating to incremental builds and caching, however the use of onlyIf 
> with file exists checks breaks many of these features, meaning you 
> must run clean task before every build to get a fresh build. This 
> could cause some confusion for people who are familiar with Gradle's 
> normal operation. This isn't really that big of an issue, but might be 
> something to consider in the future.
>
> 3. General cleanup/improvements
> A lot of things could be generally cleaned/improved up, for example:
> - `options.compilerArgs.addAll(['--release', '18'])` can become 
> `options.release = 18`
> - `dependsOn jar` in addMainModuleInfo would be more technically 
> correct than `dependsOn build`
> - making build task depend on jpackage task so that build (the normal 
> gradle task to build a project) creates the executable.
> - improvements to libclang path handling are already being worked on 
> at https://github.com/openjdk/jextract/pull/8
>
> I would be willing to make pull request(s) for #1 and #3 if those are 
> desired changes and if JBS issues can be created.
>
> -DJ
>
> On 3/23/2022 5:50 PM, Maurizio Cimadamore wrote:
>> Hi,
>> as anticipated in [1], jextract has finally landed in its own 
>> standalone repository:
>>
>> https://github.com/openjdk/jextract
>>
>> The version of jextract included in this repo is suitable to work 
>> with Java 18 (just hot off the press!), and we plan to create new 
>> branches as new Java versions will come out (to make it easy to find 
>> the version you want to work with).
>>
>> The jextract sources can be built using gradle; as usual, the build 
>> depends on libclang, so a LLVM binary snapshot is required [2]. 
>> Testing is also possible (requires jtreg).
>>
>> Jextract binary snapshots will be made available at a later date. 
>> Moving forward, we will gradually phase out the jextract branch 
>> (foreign-jextract) of the panama/foreign repository, and work on the 
>> standalone repository instead.
>>
>> If you are interested, please give it a try, and let us know what you 
>> think.
>>
>> Cheers
>> Maurizio
>>
>> [1] - 
>> https://mail.openjdk.java.net/pipermail/panama-dev/2021-December/015895.html 
>>
>> [2] - https://releases.llvm.org/download.html
>>
>>