jextract standalone repository

[Daniel Jarabek]

Hi,

I am ready to contribute my changes, however my OCA is still under 
review. Is there some way to speed up the review process or do I just 
need to wait? Should I make the pull request anyways even though my OCA 
has not yet been reviewed?

-DJ

On 3/28/2022 6:14 AM, Maurizio Cimadamore wrote:
> 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
>>>
>>>