From sundararajan.athijegannathan at oracle.com  Thu Mar 17 01:58:46 2022
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Thu, 17 Mar 2022 01:58:46 +0000
Subject: Test email - please ignore
Message-ID: <MWHPR10MB185454F4E1143055B9A91884EA129@MWHPR10MB1854.namprd10.prod.outlook.com>

Test email - please ignore

-Sundar

From sundar at openjdk.java.net  Thu Mar 17 03:26:23 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Thu, 17 Mar 2022 03:26:23 GMT
Subject: RFR: 7903121: initial jextract tool code, tests and samples
Message-ID: <6ZWktM9nlco08cpxV0C5Wx-YtEMb6h_081psTBvUrvA=.0c240bc8-3314-4303-87ae-166a1be2ae9b@github.com>

Adding initial standalone jextract code, tests and samples.

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

Commit messages:
 - 7903121: initial jextract tool code, tests and samples
 - fixed whitespaces, tabs and executable permission.
 - initial commit

Changes: https://git.openjdk.java.net/jextract/pull/2/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jextract&pr=2&range=00
  Issue: https://bugs.openjdk.java.net/browse/CODETOOLS-7903121
  Stats: 34702 lines in 401 files changed: 34699 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jextract/pull/2.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/2/head:pull/2

PR: https://git.openjdk.java.net/jextract/pull/2

From mcimadamore at openjdk.java.net  Mon Mar 21 17:36:54 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 21 Mar 2022 17:36:54 GMT
Subject: RFR: 7903121: initial jextract tool code, tests and samples
In-Reply-To: <6ZWktM9nlco08cpxV0C5Wx-YtEMb6h_081psTBvUrvA=.0c240bc8-3314-4303-87ae-166a1be2ae9b@github.com>
References: <6ZWktM9nlco08cpxV0C5Wx-YtEMb6h_081psTBvUrvA=.0c240bc8-3314-4303-87ae-166a1be2ae9b@github.com>
Message-ID: <I4QgZhbPg6xYwDafBOIt2oq5QhYmFF8IUjMWdVMc_cQ=.da239c85-9e24-441c-a061-e94654905d31@github.com>

On Thu, 17 Mar 2022 02:16:06 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Adding initial standalone jextract code, tests and samples.

Looks good. I've tested the build on linux-x64 and it works ok. I've added some minor comments to make things a bit more consistent.

README.md line 157:

> 155: 
> 156: 
> 157: #### Building jextract tool

You probably want just `###` in these sections (for uniformity)

README.md line 172:

> 170: ```sh
> 171: 
> 172: $ sh ./gradlew -Pjdk18_home=<jdk18_home_dir> -PLIBCLANG_HOME=<libclang_dir> clean verify

I think the clang property should be lowercase, for consistency with other properties

README.md line 172:

> 170: ```sh
> 171: 
> 172: $ sh ./gradlew -Pjdk18_home=<jdk18_home_dir> -PLIBCLANG_HOME=<libclang_dir> clean verify

I think the clang property should be lowercase, for consistency with other properties

README.md line 191:

> 189: ### jextract samples
> 190: 
> 191: jextract samples can be found "samples" top-level directory. Building/running particular sample may require

This should probably go somewhere more toplevel - e.g. in the first intro - but I'll do another pass on the document after you push.

README.md line 191:

> 189: ### jextract samples
> 190: 
> 191: jextract samples can be found "samples" top-level directory. Building/running particular sample may require

This should probably go somewhere more toplevel - e.g. in the first intro - but I'll do another pass on the document after you push.

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

PR: https://git.openjdk.java.net/jextract/pull/2

From mcimadamore at openjdk.java.net  Mon Mar 21 18:01:43 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 21 Mar 2022 18:01:43 GMT
Subject: RFR: 7903121: initial jextract tool code, tests and samples
In-Reply-To: <6ZWktM9nlco08cpxV0C5Wx-YtEMb6h_081psTBvUrvA=.0c240bc8-3314-4303-87ae-166a1be2ae9b@github.com>
References: <6ZWktM9nlco08cpxV0C5Wx-YtEMb6h_081psTBvUrvA=.0c240bc8-3314-4303-87ae-166a1be2ae9b@github.com>
Message-ID: <-S_ye82ytHC8ysbu15zRdC5H-rMZv1AD5alIEiPcNQ0=.8658a520-2cc4-429b-b9a6-154ee7de6caf@github.com>

On Thu, 17 Mar 2022 02:16:06 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Adding initial standalone jextract code, tests and samples.

README.md line 157:

> 155: 
> 156: 
> 157: #### Building jextract tool

You probably want just `###` in these sections (for uniformity)

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

PR: https://git.openjdk.java.net/jextract/pull/2

From sundar at openjdk.java.net  Wed Mar 23 05:26:26 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Wed, 23 Mar 2022 05:26:26 GMT
Subject: RFR: 7903121: initial jextract tool code, tests and samples [v2]
In-Reply-To: <6ZWktM9nlco08cpxV0C5Wx-YtEMb6h_081psTBvUrvA=.0c240bc8-3314-4303-87ae-166a1be2ae9b@github.com>
References: <6ZWktM9nlco08cpxV0C5Wx-YtEMb6h_081psTBvUrvA=.0c240bc8-3314-4303-87ae-166a1be2ae9b@github.com>
Message-ID: <_k4YJ1b4m4_rgK4U_n6KTQGEiK3rL0U1xZiZrdxvmWg=.0b40729a-f43a-43ab-ba8a-834fc8049151@github.com>

> Adding initial standalone jextract code, tests and samples.

Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:

  Fixed README.md for consistent section headers

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/2/files
  - new: https://git.openjdk.java.net/jextract/pull/2/files/d3a7edfe..a9ad807c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=2&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=2&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jextract/pull/2.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/2/head:pull/2

PR: https://git.openjdk.java.net/jextract/pull/2

From sundar at openjdk.java.net  Wed Mar 23 05:26:27 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Wed, 23 Mar 2022 05:26:27 GMT
Subject: RFR: 7903121: initial jextract tool code, tests and samples [v2]
In-Reply-To: <I4QgZhbPg6xYwDafBOIt2oq5QhYmFF8IUjMWdVMc_cQ=.da239c85-9e24-441c-a061-e94654905d31@github.com>
References: <6ZWktM9nlco08cpxV0C5Wx-YtEMb6h_081psTBvUrvA=.0c240bc8-3314-4303-87ae-166a1be2ae9b@github.com>
 <I4QgZhbPg6xYwDafBOIt2oq5QhYmFF8IUjMWdVMc_cQ=.da239c85-9e24-441c-a061-e94654905d31@github.com>
Message-ID: <q9CgXSA-OH1XOlC22jxkfnymdkEUPnB6kJXSCZgvEls=.e2cfb75d-3328-4176-b3ea-2c8b277953b6@github.com>

On Mon, 21 Mar 2022 17:31:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed README.md for consistent section headers
>
> README.md line 157:
> 
>> 155: 
>> 156: 
>> 157: #### Building jextract tool
> 
> You probably want just `###` in these sections (for uniformity)

Fixed that.

> README.md line 191:
> 
>> 189: ### jextract samples
>> 190: 
>> 191: jextract samples can be found "samples" top-level directory. Building/running particular sample may require
> 
> This should probably go somewhere more toplevel - e.g. in the first intro - but I'll do another pass on the document after you push.

sounds good.

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

PR: https://git.openjdk.java.net/jextract/pull/2

From sundar at openjdk.java.net  Wed Mar 23 05:33:32 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Wed, 23 Mar 2022 05:33:32 GMT
Subject: RFR: 7903121: initial jextract tool code, tests and samples [v3]
In-Reply-To: <6ZWktM9nlco08cpxV0C5Wx-YtEMb6h_081psTBvUrvA=.0c240bc8-3314-4303-87ae-166a1be2ae9b@github.com>
References: <6ZWktM9nlco08cpxV0C5Wx-YtEMb6h_081psTBvUrvA=.0c240bc8-3314-4303-87ae-166a1be2ae9b@github.com>
Message-ID: <wy2YayoJ39hXTxUXDq5HG-cXPrrtMUGyquMXwYiGaW0=.f19d052d-5704-4c85-a509-8d6975d15676@github.com>

> Adding initial standalone jextract code, tests and samples.

Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:

  changed LIBCLANG_HOME property name to libclang_home

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/2/files
  - new: https://git.openjdk.java.net/jextract/pull/2/files/a9ad807c..74e16ab7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=2&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=2&range=01-02

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jextract/pull/2.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/2/head:pull/2

PR: https://git.openjdk.java.net/jextract/pull/2

From sundar at openjdk.java.net  Wed Mar 23 05:33:33 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Wed, 23 Mar 2022 05:33:33 GMT
Subject: RFR: 7903121: initial jextract tool code, tests and samples [v3]
In-Reply-To: <I4QgZhbPg6xYwDafBOIt2oq5QhYmFF8IUjMWdVMc_cQ=.da239c85-9e24-441c-a061-e94654905d31@github.com>
References: <6ZWktM9nlco08cpxV0C5Wx-YtEMb6h_081psTBvUrvA=.0c240bc8-3314-4303-87ae-166a1be2ae9b@github.com>
 <I4QgZhbPg6xYwDafBOIt2oq5QhYmFF8IUjMWdVMc_cQ=.da239c85-9e24-441c-a061-e94654905d31@github.com>
Message-ID: <IdsRG2R-k03Ks9vcmQkrwcpcK373wxLgI1pKsKIrA6U=.b8e7d9f4-8740-417a-bf3c-d25c31ae6296@github.com>

On Mon, 21 Mar 2022 17:32:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changed LIBCLANG_HOME property name to libclang_home
>
> README.md line 191:
> 
>> 189: ### jextract samples
>> 190: 
>> 191: jextract samples can be found "samples" top-level directory. Building/running particular sample may require
> 
> This should probably go somewhere more toplevel - e.g. in the first intro - but I'll do another pass on the document after you push.

sounds good

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

PR: https://git.openjdk.java.net/jextract/pull/2

From mcimadamore at openjdk.java.net  Wed Mar 23 15:56:51 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 23 Mar 2022 15:56:51 GMT
Subject: RFR: 7903121: initial jextract tool code, tests and samples [v3]
In-Reply-To: <wy2YayoJ39hXTxUXDq5HG-cXPrrtMUGyquMXwYiGaW0=.f19d052d-5704-4c85-a509-8d6975d15676@github.com>
References: <6ZWktM9nlco08cpxV0C5Wx-YtEMb6h_081psTBvUrvA=.0c240bc8-3314-4303-87ae-166a1be2ae9b@github.com>
 <wy2YayoJ39hXTxUXDq5HG-cXPrrtMUGyquMXwYiGaW0=.f19d052d-5704-4c85-a509-8d6975d15676@github.com>
Message-ID: <kkkJdZpgRaIxdfk6TwmaoodN6m5jsSKuv-xdE4-TIl8=.a888e9e7-4198-40a8-b319-7804f9188f7e@github.com>

On Wed, 23 Mar 2022 05:33:32 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> Adding initial standalone jextract code, tests and samples.
>
> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed LIBCLANG_HOME property name to libclang_home

Marked as reviewed by mcimadamore (Committer).

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

PR: https://git.openjdk.java.net/jextract/pull/2

From jvernee at openjdk.java.net  Wed Mar 23 17:58:37 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 23 Mar 2022 17:58:37 GMT
Subject: RFR: 7903121: initial jextract tool code, tests and samples [v3]
In-Reply-To: <wy2YayoJ39hXTxUXDq5HG-cXPrrtMUGyquMXwYiGaW0=.f19d052d-5704-4c85-a509-8d6975d15676@github.com>
References: <6ZWktM9nlco08cpxV0C5Wx-YtEMb6h_081psTBvUrvA=.0c240bc8-3314-4303-87ae-166a1be2ae9b@github.com>
 <wy2YayoJ39hXTxUXDq5HG-cXPrrtMUGyquMXwYiGaW0=.f19d052d-5704-4c85-a509-8d6975d15676@github.com>
Message-ID: <gsW5qr6i6Jrf9UnfcwTL-wqWrur-0oEfEl9RG1-9wOQ=.ef4e2d33-79fd-4e9a-a622-5f73639304d7@github.com>

On Wed, 23 Mar 2022 05:33:32 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> Adding initial standalone jextract code, tests and samples.
>
> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed LIBCLANG_HOME property name to libclang_home

Works on Windows

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

Marked as reviewed by jvernee (no project role).

PR: https://git.openjdk.java.net/jextract/pull/2

From sundar at openjdk.java.net  Wed Mar 23 19:35:41 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Wed, 23 Mar 2022 19:35:41 GMT
Subject: Integrated: 7903121: initial jextract tool code, tests and samples
In-Reply-To: <6ZWktM9nlco08cpxV0C5Wx-YtEMb6h_081psTBvUrvA=.0c240bc8-3314-4303-87ae-166a1be2ae9b@github.com>
References: <6ZWktM9nlco08cpxV0C5Wx-YtEMb6h_081psTBvUrvA=.0c240bc8-3314-4303-87ae-166a1be2ae9b@github.com>
Message-ID: <UlJJ4i1ZHvNi1wmpjGZPd3-c8oPRJkvxnA1LUMmYwVY=.1ddb59f2-7e03-4a76-88b1-5511a0595217@github.com>

On Thu, 17 Mar 2022 02:16:06 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Adding initial standalone jextract code, tests and samples.

This pull request has now been integrated.

Changeset: c1d78132
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jextract/commit/c1d78132d92fdd56e4761e6fef57c54ea8048b22
Stats:     34702 lines in 401 files changed: 34699 ins; 2 del; 1 mod

7903121: initial jextract tool code, tests and samples

Reviewed-by: mcimadamore, jvernee

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

PR: https://git.openjdk.java.net/jextract/pull/2

From mcimadamore at openjdk.java.net  Thu Mar 24 13:09:22 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 13:09:22 GMT
Subject: RFR: 7903128: Overhaul jextract README
Message-ID: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>

I've improved the README file, by putting the expanding the build section, and putting it more front and center.
I have also streamlined the remaining contents a little, and removed the parts that were describing the foreign API (not really needed here).

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

Commit messages:
 - Overhaul README

Changes: https://git.openjdk.java.net/jextract/pull/3/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jextract&pr=3&range=00
  Issue: https://bugs.openjdk.java.net/browse/CODETOOLS-7903128
  Stats: 116 lines in 1 file changed: 28 ins; 68 del; 20 mod
  Patch: https://git.openjdk.java.net/jextract/pull/3.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/3/head:pull/3

PR: https://git.openjdk.java.net/jextract/pull/3

From mcimadamore at openjdk.java.net  Thu Mar 24 13:15:44 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 13:15:44 GMT
Subject: RFR: 7903128: Overhaul jextract README [v2]
In-Reply-To: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
References: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
Message-ID: <i1OL6cit-DVA9X1_F-yx5qYm9a81Y70aR2FpofUbNOo=.e0ab5300-3cb1-4cd6-84cf-db347ead7518@github.com>

> I've improved the README file, by putting the expanding the build section, and putting it more front and center.
> I have also streamlined the remaining contents a little, and removed the parts that were describing the foreign API (not really needed here).

Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:

 - Simplify dir tree structure
 - More fixes

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/3/files
  - new: https://git.openjdk.java.net/jextract/pull/3/files/8c0a2f9b..b2b97d16

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=3&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=3&range=00-01

  Stats: 22 lines in 1 file changed: 0 ins; 15 del; 7 mod
  Patch: https://git.openjdk.java.net/jextract/pull/3.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/3/head:pull/3

PR: https://git.openjdk.java.net/jextract/pull/3

From sundar at openjdk.java.net  Thu Mar 24 13:57:07 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Thu, 24 Mar 2022 13:57:07 GMT
Subject: RFR: 7903128: Overhaul jextract README [v2]
In-Reply-To: <i1OL6cit-DVA9X1_F-yx5qYm9a81Y70aR2FpofUbNOo=.e0ab5300-3cb1-4cd6-84cf-db347ead7518@github.com>
References: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
 <i1OL6cit-DVA9X1_F-yx5qYm9a81Y70aR2FpofUbNOo=.e0ab5300-3cb1-4cd6-84cf-db347ead7518@github.com>
Message-ID: <jl7W5LlgZ-qiR3cH27SjTCaj7aHNgxWQI88rEI9lpSE=.06e54c77-b957-4161-888b-c9388f23db8f@github.com>

On Thu, 24 Mar 2022 13:15:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I've improved the README file, by putting the expanding the build section, and putting it more front and center.
>> I have also streamlined the remaining contents a little, and removed the parts that were describing the foreign API (not really needed here).
>
> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Simplify dir tree structure
>  - More fixes

LGTM

README.md line 15:

> 13: ```
> 14: 
> 15: After building, there should be a new `jextract` folder under `build` (the contents of this folder might vary depending on the platform):

Folder name is jextract.app on Mac. i.e., even folder name depends on platform

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

Marked as reviewed by sundar (no project role).

PR: https://git.openjdk.java.net/jextract/pull/3

From jvernee at openjdk.java.net  Thu Mar 24 13:57:11 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 24 Mar 2022 13:57:11 GMT
Subject: RFR: 7903128: Overhaul jextract README [v2]
In-Reply-To: <i1OL6cit-DVA9X1_F-yx5qYm9a81Y70aR2FpofUbNOo=.e0ab5300-3cb1-4cd6-84cf-db347ead7518@github.com>
References: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
 <i1OL6cit-DVA9X1_F-yx5qYm9a81Y70aR2FpofUbNOo=.e0ab5300-3cb1-4cd6-84cf-db347ead7518@github.com>
Message-ID: <4cSuQXHxtByeMgcrAzZ3kkeSm_itXEt4gD5tuIFbwHk=.bca86c02-752b-4bde-ac56-8b34c16970a0@github.com>

On Thu, 24 Mar 2022 13:15:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I've improved the README file, by putting the expanding the build section, and putting it more front and center.
>> I have also streamlined the remaining contents a little, and removed the parts that were describing the foreign API (not really needed here).
>
> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Simplify dir tree structure
>  - More fixes

Very nice!

Minor nits inline

README.md line 3:

> 1: ## Jextract
> 2: 
> 3: `jextract` is a tool which mechanically generates Java bindings from a native library headers. This tools leverages the [clang C API](https://clang.llvm.org/doxygen/group__CINDEX.html) in order to parse the headers associated to a given native library, and the generated Java bindings builds upon the [Foreign Function & Memory API](https://openjdk.java.net/jeps/419). The `jextract` tool was originally developed in the context of [Project Panama](https://openjdk.java.net/projects/panama/) (and then made available in the Project Panama [Early Access binaries](https://jdk.java.net/panama/)).

Suggestion:

`jextract` is a tool which mechanically generates Java bindings from a native library headers. This tools leverages the [clang C API](https://clang.llvm.org/doxygen/group__CINDEX.html) in order to parse the headers associated with a given native library, and the generated Java bindings build upon the [Foreign Function & Memory API](https://openjdk.java.net/jeps/419). The `jextract` tool was originally developed in the context of [Project Panama](https://openjdk.java.net/projects/panama/) (and then made available in the Project Panama [Early Access binaries](https://jdk.java.net/panama/)).

README.md line 7:

> 5: ### Getting started
> 6: 
> 7: `jextract` depends on the [C libclang API](https://clang.llvm.org/doxygen/group__CINDEX.html). To build the jextract sources, the easiest option is to download LLVM binaries for your platform, which can be found [here](https://releases.llvm.org/download.html). Both the `jextract` tool and the bindings it generates depend heavily on the [Foreign Function & Memory API](https://openjdk.java.net/jeps/419), so a suitable [jdk 18 distribution](https://jdk.java.net/18/) is also required.

I think this should say something about which version of LLVM should be used, and is expected to work.
Suggestion:

`jextract` depends on the [C libclang API](https://clang.llvm.org/doxygen/group__CINDEX.html). To build the jextract sources, the easiest option is to download LLVM binaries for your platform, which can be found [here](https://releases.llvm.org/download.html). Any version from 9 and up should work. Both the `jextract` tool and the bindings it generates depend heavily on the [Foreign Function & Memory API](https://openjdk.java.net/jeps/419), so a suitable [jdk 18 distribution](https://jdk.java.net/18/) is also required.

README.md line 33:

> 31: 
> 32: ```sh
> 33: build/jextract/bin/jextract 

for me the exe is under `build/jextract/jextract.exe` is this different on Linux?

README.md line 115:

> 113: #### Filtering symbols
> 114: 
> 115: The `jextract` tool includes several customization options. Users can select what in which package the generated code should be emitted, and what the name of the main extracted class should be. To allow for symbol filtering, `jextract` can generate a *dump* of all the symbols encountered in an header file; this dump can be manipulated, and then used as an argument file (using the `@argfile` syntax also available in other JDK tools) to e.g. generate bindings only for a *subset* of symbols seen by `jextract`. For instance, if we run `jextract` with as follows:

Suggestion:

The `jextract` tool includes several customization options. Users can select in which package the generated code should be emitted, and what the name of the main extracted class should be. To allow for symbol filtering, `jextract` can generate a *dump* of all the symbols encountered in an header file; this dump can be manipulated, and then used as an argument file (using the `@argfile` syntax also available in other JDK tools) to e.g. generate bindings only for a *subset* of symbols seen by `jextract`. For instance, if we run `jextract` with as follows:

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

Marked as reviewed by jvernee (no project role).

PR: https://git.openjdk.java.net/jextract/pull/3

From jvernee at openjdk.java.net  Thu Mar 24 13:57:12 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 24 Mar 2022 13:57:12 GMT
Subject: RFR: 7903128: Overhaul jextract README [v2]
In-Reply-To: <4cSuQXHxtByeMgcrAzZ3kkeSm_itXEt4gD5tuIFbwHk=.bca86c02-752b-4bde-ac56-8b34c16970a0@github.com>
References: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
 <i1OL6cit-DVA9X1_F-yx5qYm9a81Y70aR2FpofUbNOo=.e0ab5300-3cb1-4cd6-84cf-db347ead7518@github.com>
 <4cSuQXHxtByeMgcrAzZ3kkeSm_itXEt4gD5tuIFbwHk=.bca86c02-752b-4bde-ac56-8b34c16970a0@github.com>
Message-ID: <mDQq1J8aDwdQ3VT07mGVeuQmMDJ9feDFQsdr8Yj3il4=.bdc1d717-996e-43c2-ad0b-5d7168058524@github.com>

On Thu, 24 Mar 2022 13:49:41 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Simplify dir tree structure
>>  - More fixes
>
> README.md line 115:
> 
>> 113: #### Filtering symbols
>> 114: 
>> 115: The `jextract` tool includes several customization options. Users can select what in which package the generated code should be emitted, and what the name of the main extracted class should be. To allow for symbol filtering, `jextract` can generate a *dump* of all the symbols encountered in an header file; this dump can be manipulated, and then used as an argument file (using the `@argfile` syntax also available in other JDK tools) to e.g. generate bindings only for a *subset* of symbols seen by `jextract`. For instance, if we run `jextract` with as follows:
> 
> Suggestion:
> 
> The `jextract` tool includes several customization options. Users can select in which package the generated code should be emitted, and what the name of the main extracted class should be. To allow for symbol filtering, `jextract` can generate a *dump* of all the symbols encountered in an header file; this dump can be manipulated, and then used as an argument file (using the `@argfile` syntax also available in other JDK tools) to e.g. generate bindings only for a *subset* of symbols seen by `jextract`. For instance, if we run `jextract` with as follows:

I think this should also mention the corresponding command line options. i.e. `-t`, `--header-class-name`. For filtering the example below is good enough

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

PR: https://git.openjdk.java.net/jextract/pull/3

From mcimadamore at openjdk.java.net  Thu Mar 24 14:06:37 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 14:06:37 GMT
Subject: RFR: 7903128: Overhaul jextract README [v3]
In-Reply-To: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
References: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
Message-ID: <lByEbrLSx9c-uoNXlxgpmPA4-wf1Ymw8b6ZIfhMFjeI=.fe9d2c0c-784b-4b0c-89e7-9d36a132c39e@github.com>

> I've improved the README file, by putting the expanding the build section, and putting it more front and center.
> I have also streamlined the remaining contents a little, and removed the parts that were describing the foreign API (not really needed here).

Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:

 - Update README.md
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update README.md
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/3/files
  - new: https://git.openjdk.java.net/jextract/pull/3/files/b2b97d16..e0f7e3bc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=3&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=3&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jextract/pull/3.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/3/head:pull/3

PR: https://git.openjdk.java.net/jextract/pull/3

From mcimadamore at openjdk.java.net  Thu Mar 24 14:06:38 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 14:06:38 GMT
Subject: RFR: 7903128: Overhaul jextract README [v2]
In-Reply-To: <4cSuQXHxtByeMgcrAzZ3kkeSm_itXEt4gD5tuIFbwHk=.bca86c02-752b-4bde-ac56-8b34c16970a0@github.com>
References: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
 <i1OL6cit-DVA9X1_F-yx5qYm9a81Y70aR2FpofUbNOo=.e0ab5300-3cb1-4cd6-84cf-db347ead7518@github.com>
 <4cSuQXHxtByeMgcrAzZ3kkeSm_itXEt4gD5tuIFbwHk=.bca86c02-752b-4bde-ac56-8b34c16970a0@github.com>
Message-ID: <8vsDjpbfMX1ERMu_p-HtkpwPdS-ewkSJcIRln6WgAeU=.7bf72e36-f2f1-49d0-ba26-631cc7cdae50@github.com>

On Thu, 24 Mar 2022 13:53:34 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Simplify dir tree structure
>>  - More fixes
>
> README.md line 33:
> 
>> 31: 
>> 32: ```sh
>> 33: build/jextract/bin/jextract 
> 
> for me the exe is under `build/jextract/jextract.exe` is this different on Linux?

Yep  -this is different on my machine

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

PR: https://git.openjdk.java.net/jextract/pull/3

From mcimadamore at openjdk.java.net  Thu Mar 24 14:13:41 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 14:13:41 GMT
Subject: RFR: 7903128: Overhaul jextract README [v4]
In-Reply-To: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
References: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
Message-ID: <F-9RbCw8txdUX7mjii31Y4G40OWrfhx8NJTajDTpBxY=.99b27ff3-7c3e-4f85-8f36-f3860a974f16@github.com>

> I've improved the README file, by putting the expanding the build section, and putting it more front and center.
> I have also streamlined the remaining contents a little, and removed the parts that were describing the foreign API (not really needed here).

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'master' into readme-changes
 - Update README.md
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update README.md
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Simplify dir tree structure
 - More fixes
 - Overhaul README

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/3/files
  - new: https://git.openjdk.java.net/jextract/pull/3/files/e0f7e3bc..380f9a6b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=3&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=3&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jextract/pull/3.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/3/head:pull/3

PR: https://git.openjdk.java.net/jextract/pull/3

From jvernee at openjdk.java.net  Thu Mar 24 14:13:41 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 24 Mar 2022 14:13:41 GMT
Subject: RFR: 7903128: Overhaul jextract README [v3]
In-Reply-To: <lByEbrLSx9c-uoNXlxgpmPA4-wf1Ymw8b6ZIfhMFjeI=.fe9d2c0c-784b-4b0c-89e7-9d36a132c39e@github.com>
References: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
 <lByEbrLSx9c-uoNXlxgpmPA4-wf1Ymw8b6ZIfhMFjeI=.fe9d2c0c-784b-4b0c-89e7-9d36a132c39e@github.com>
Message-ID: <br_G_-CBkUu5qQzbJQaw7JTC-2qH7V5SeWcie7RO73M=.85d802b5-760c-4e7a-a0a6-5b082516b2f8@github.com>

On Thu, 24 Mar 2022 14:06:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I've improved the README file, by putting the expanding the build section, and putting it more front and center.
>> I have also streamlined the remaining contents a little, and removed the parts that were describing the foreign API (not really needed here).
>
> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update README.md
>    
>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>  - Update README.md
>    
>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

Marked as reviewed by jvernee (no project role).

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

PR: https://git.openjdk.java.net/jextract/pull/3

From mcimadamore at openjdk.java.net  Thu Mar 24 14:55:31 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 14:55:31 GMT
Subject: RFR: 7903128: Overhaul jextract README [v5]
In-Reply-To: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
References: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
Message-ID: <syNqJLRAEylbHNqBVISuanXpMBUW98-hO2srR-hRwXM=.e583ad37-1279-4649-94c2-4882453eb8d1@github.com>

> I've improved the README file, by putting the expanding the build section, and putting it more front and center.
> I have also streamlined the remaining contents a little, and removed the parts that were describing the foreign API (not really needed here).

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/3/files
  - new: https://git.openjdk.java.net/jextract/pull/3/files/380f9a6b..7092d796

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=3&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=3&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jextract/pull/3.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/3/head:pull/3

PR: https://git.openjdk.java.net/jextract/pull/3

From jvernee at openjdk.java.net  Thu Mar 24 14:55:32 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 24 Mar 2022 14:55:32 GMT
Subject: RFR: 7903128: Overhaul jextract README [v5]
In-Reply-To: <syNqJLRAEylbHNqBVISuanXpMBUW98-hO2srR-hRwXM=.e583ad37-1279-4649-94c2-4882453eb8d1@github.com>
References: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
 <syNqJLRAEylbHNqBVISuanXpMBUW98-hO2srR-hRwXM=.e583ad37-1279-4649-94c2-4882453eb8d1@github.com>
Message-ID: <2M7iHVlv0aZ56FV1uun9HvcWOk2OeOZuj1sXpw-KfL0=.76c7b76d-06cd-4c23-90b8-b7ca308ba8f0@github.com>

On Thu, 24 Mar 2022 14:51:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I've improved the README file, by putting the expanding the build section, and putting it more front and center.
>> I have also streamlined the remaining contents a little, and removed the parts that were describing the foreign API (not really needed here).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

README.md line 7:

> 5: ### Getting started
> 6: 
> 7: `jextract` depends on the [C libclang API](https://clang.llvm.org/doxygen/group__CINDEX.html). To build the jextract sources, the easiest option is to download LLVM binaries for your platform, which can be found [here](https://releases.llvm.org/download.html) (a version <= 9 is required). Both the `jextract` tool and the bindings it generates depend heavily on the [Foreign Function & Memory API](https://openjdk.java.net/jeps/419), so a suitable [jdk 18 distribution](https://jdk.java.net/18/) is also required.

should be `version >= 9` right?

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

PR: https://git.openjdk.java.net/jextract/pull/3

From mcimadamore at openjdk.java.net  Thu Mar 24 15:15:53 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 15:15:53 GMT
Subject: RFR: 7903128: Overhaul jextract README [v6]
In-Reply-To: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
References: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
Message-ID: <PXGcNZUYcedJwwG209_i2Oslzg21vYDEV6OyLQQHFrM=.ffc4b97a-e277-4cfb-a48b-dec6a25c6bab@github.com>

> I've improved the README file, by putting the expanding the build section, and putting it more front and center.
> I have also streamlined the remaining contents a little, and removed the parts that were describing the foreign API (not really needed here).

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Add list of command line options

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/3/files
  - new: https://git.openjdk.java.net/jextract/pull/3/files/7092d796..45c65328

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=3&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=3&range=04-05

  Stats: 16 lines in 1 file changed: 15 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jextract/pull/3.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/3/head:pull/3

PR: https://git.openjdk.java.net/jextract/pull/3

From mcimadamore at openjdk.java.net  Thu Mar 24 15:28:46 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 15:28:46 GMT
Subject: RFR: 7903128: Overhaul jextract README [v7]
In-Reply-To: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
References: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
Message-ID: <OyeLatLXEZNUBra79YhTgrKunqAy7PUI-NZ7hqmAPgw=.acd10299-59fe-429a-a2cf-6663a4ad1d85@github.com>

> I've improved the README file, by putting the expanding the build section, and putting it more front and center.
> I have also streamlined the remaining contents a little, and removed the parts that were describing the foreign API (not really needed here).

Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:

 - Fix issue with libclang version
 - More table tweaks
 - Tweak table

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/3/files
  - new: https://git.openjdk.java.net/jextract/pull/3/files/45c65328..a6435517

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=3&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=3&range=05-06

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jextract/pull/3.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/3/head:pull/3

PR: https://git.openjdk.java.net/jextract/pull/3

From jvernee at openjdk.java.net  Thu Mar 24 15:41:07 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 24 Mar 2022 15:41:07 GMT
Subject: RFR: 7903128: Overhaul jextract README [v7]
In-Reply-To: <OyeLatLXEZNUBra79YhTgrKunqAy7PUI-NZ7hqmAPgw=.acd10299-59fe-429a-a2cf-6663a4ad1d85@github.com>
References: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
 <OyeLatLXEZNUBra79YhTgrKunqAy7PUI-NZ7hqmAPgw=.acd10299-59fe-429a-a2cf-6663a4ad1d85@github.com>
Message-ID: <UZWlMq8ZaitVoXYL1TNOyDMmCMKzSvfdt6MF9_-N3Po=.58bdd7df-b78f-4e15-9cb4-5f25afa38868@github.com>

On Thu, 24 Mar 2022 15:28:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I've improved the README file, by putting the expanding the build section, and putting it more front and center.
>> I have also streamlined the remaining contents a little, and removed the parts that were describing the foreign API (not really needed here).
>
> Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix issue with libclang version
>  - More table tweaks
>  - Tweak table

Looks good.

README.md line 119:

> 117: | Option                                                       | Meaning                                                      |
> 118: | :----------------------------------------------------------- | ------------------------------------------------------------ |
> 119: | `--header-class-name <String>`                               | specify the name the main header class                       |

Suggestion:

| `--header-class-name <String>`                               | specify the name of the main header class                       |

README.md line 126:

> 124: | `--source`                                                   | generate java sources instead of classfiles                  |
> 125: | `--dump-includes <String>`                                   | dump included symbols into specified file (see below)        |
> 126: | `--include-[function,macro,struct,union,typedef,var]<String>` | Include a symbol of the given name and kind in the generated bindings (see below). When one of these options is specified, any symbols that is not matched by any specified filters is omitted from the generated bindings. |

Suggestion:

| `--include-[function,macro,struct,union,typedef,var]<String>` | Include a symbol of the given name and kind in the generated bindings (see below). When one of these options is specified, any symbol that is not matched by any specified filters is omitted from the generated bindings. |

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

Marked as reviewed by jvernee (no project role).

PR: https://git.openjdk.java.net/jextract/pull/3

From sundar at openjdk.java.net  Thu Mar 24 15:49:58 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Thu, 24 Mar 2022 15:49:58 GMT
Subject: RFR: 7903128: Overhaul jextract README [v7]
In-Reply-To: <UZWlMq8ZaitVoXYL1TNOyDMmCMKzSvfdt6MF9_-N3Po=.58bdd7df-b78f-4e15-9cb4-5f25afa38868@github.com>
References: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
 <OyeLatLXEZNUBra79YhTgrKunqAy7PUI-NZ7hqmAPgw=.acd10299-59fe-429a-a2cf-6663a4ad1d85@github.com>
 <UZWlMq8ZaitVoXYL1TNOyDMmCMKzSvfdt6MF9_-N3Po=.58bdd7df-b78f-4e15-9cb4-5f25afa38868@github.com>
Message-ID: <miFsHv_kZci9H5ZriJ1jRs0SkH14FDoeEPr-cA3_1Fc=.ffb3a268-3ad2-42fa-ad9a-f0c53d78ac38@github.com>

On Thu, 24 Mar 2022 15:37:57 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Fix issue with libclang version
>>  - More table tweaks
>>  - Tweak table
>
> README.md line 126:
> 
>> 124: | `--source`                                                   | generate java sources instead of classfiles                  |
>> 125: | `--dump-includes <String>`                                   | dump included symbols into specified file (see below)        |
>> 126: | `--include-[function,macro,struct,union,typedef,var]<String>` | Include a symbol of the given name and kind in the generated bindings (see below). When one of these options is specified, any symbols that is not matched by any specified filters is omitted from the generated bindings. |
> 
> Suggestion:
> 
> | `--include-[function,macro,struct,union,typedef,var]<String>` | Include a symbol of the given name and kind in the generated bindings (see below). When one of these options is specified, any symbol that is not matched by any specified filters is omitted from the generated bindings. |

looks good

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

PR: https://git.openjdk.java.net/jextract/pull/3

From mcimadamore at openjdk.java.net  Thu Mar 24 15:56:38 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 15:56:38 GMT
Subject: RFR: 7903128: Overhaul jextract README [v8]
In-Reply-To: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
References: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
Message-ID: <X0NflWg0eEImhC-VD_pf2FfS3M6DK1rAfPo-KyLCXP0=.0b1f514c-0e1d-4bac-9d03-69c9c0b1f93f@github.com>

> I've improved the README file, by putting the expanding the build section, and putting it more front and center.
> I have also streamlined the remaining contents a little, and removed the parts that were describing the foreign API (not really needed here).

Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:

 - Update README.md
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update README.md
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/3/files
  - new: https://git.openjdk.java.net/jextract/pull/3/files/a6435517..79418a28

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=3&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=3&range=06-07

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jextract/pull/3.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/3/head:pull/3

PR: https://git.openjdk.java.net/jextract/pull/3

From mcimadamore at openjdk.java.net  Thu Mar 24 15:56:38 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 15:56:38 GMT
Subject: Integrated: 7903128: Overhaul jextract README
In-Reply-To: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
References: <MRJrco_4Ub8wNaYxlj_4DpTFdxkcb1gCiDDAT_NrYAk=.52ec1023-65d8-46b0-b838-cce8db33359e@github.com>
Message-ID: <ne0x2JrtRNtJ_XcStwuU-ZBP5aF8ompFRTSEeNDMTao=.4de50fad-0835-4169-b2c4-435e49f0a0ef@github.com>

On Thu, 24 Mar 2022 13:03:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I've improved the README file, by putting the expanding the build section, and putting it more front and center.
> I have also streamlined the remaining contents a little, and removed the parts that were describing the foreign API (not really needed here).

This pull request has now been integrated.

Changeset: e6345e3a
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jextract/commit/e6345e3a40664b3ef6f837d1a88cb595d24dde47
Stats:     118 lines in 1 file changed: 28 ins; 68 del; 22 mod

7903128: Overhaul jextract README

Reviewed-by: sundar, jvernee

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

PR: https://git.openjdk.java.net/jextract/pull/3

From sundar at openjdk.java.net  Thu Mar 24 17:04:13 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Thu, 24 Mar 2022 17:04:13 GMT
Subject: RFR: 7903129: jextract does not handle @argfile
Message-ID: <xC5RHMobFybJDLHXjL6dGu_2avmxX5VfX0FXdZr440U=.91a2273e-1d5a-4f1e-8cc1-78f6acbbf326@github.com>

Missed CommandLine.parse call in JextractTool.run method.

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

Commit messages:
 - 7903129: jextract does not handle @argfile

Changes: https://git.openjdk.java.net/jextract/pull/4/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jextract&pr=4&range=00
  Issue: https://bugs.openjdk.java.net/browse/CODETOOLS-7903129
  Stats: 13 lines in 2 files changed: 13 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jextract/pull/4.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/4/head:pull/4

PR: https://git.openjdk.java.net/jextract/pull/4

From mcimadamore at openjdk.java.net  Thu Mar 24 17:10:57 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 17:10:57 GMT
Subject: RFR: 7903129: jextract does not handle @argfile
In-Reply-To: <xC5RHMobFybJDLHXjL6dGu_2avmxX5VfX0FXdZr440U=.91a2273e-1d5a-4f1e-8cc1-78f6acbbf326@github.com>
References: <xC5RHMobFybJDLHXjL6dGu_2avmxX5VfX0FXdZr440U=.91a2273e-1d5a-4f1e-8cc1-78f6acbbf326@github.com>
Message-ID: <OjaoBJgfsSq-UyhzG8xIHirppVBATIr4ouO2204AB7k=.657fc8b7-f63b-4111-a9be-b1fdcdabbef1@github.com>

On Thu, 24 Mar 2022 16:59:40 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Missed CommandLine.parse call in JextractTool.run method.

src/main/resources/org/openjdk/jextract/impl/resources/Messages.properties line 25:

> 23: 
> 24: # error message
> 25: argfile.read.error=reading @argfile failed: {0}

Can the error only occur because of arg file?

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

PR: https://git.openjdk.java.net/jextract/pull/4

From sundar at openjdk.java.net  Thu Mar 24 17:47:07 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Thu, 24 Mar 2022 17:47:07 GMT
Subject: RFR: 7903129: jextract does not handle @argfile
In-Reply-To: <OjaoBJgfsSq-UyhzG8xIHirppVBATIr4ouO2204AB7k=.657fc8b7-f63b-4111-a9be-b1fdcdabbef1@github.com>
References: <xC5RHMobFybJDLHXjL6dGu_2avmxX5VfX0FXdZr440U=.91a2273e-1d5a-4f1e-8cc1-78f6acbbf326@github.com>
 <OjaoBJgfsSq-UyhzG8xIHirppVBATIr4ouO2204AB7k=.657fc8b7-f63b-4111-a9be-b1fdcdabbef1@github.com>
Message-ID: <GqlRM3nMCRhF7_OeD9dc7BsDARWhk7kAJEWp99WTJ4c=.f5d7e51f-f078-4198-8a45-c50ec833543b@github.com>

On Thu, 24 Mar 2022 17:08:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Missed CommandLine.parse call in JextractTool.run method.
>
> src/main/resources/org/openjdk/jextract/impl/resources/Messages.properties line 25:
> 
>> 23: 
>> 24: # error message
>> 25: argfile.read.error=reading @argfile failed: {0}
> 
> Can the error only occur because of arg file?

Yes. CommandLine.parse

     * @throws IOException if there is a problem reading any of the @files

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

PR: https://git.openjdk.java.net/jextract/pull/4

From mcimadamore at openjdk.java.net  Thu Mar 24 18:26:57 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 24 Mar 2022 18:26:57 GMT
Subject: RFR: 7903129: jextract does not handle @argfile
In-Reply-To: <xC5RHMobFybJDLHXjL6dGu_2avmxX5VfX0FXdZr440U=.91a2273e-1d5a-4f1e-8cc1-78f6acbbf326@github.com>
References: <xC5RHMobFybJDLHXjL6dGu_2avmxX5VfX0FXdZr440U=.91a2273e-1d5a-4f1e-8cc1-78f6acbbf326@github.com>
Message-ID: <QboCupWELgPIOCh8AiareB5wDpuLQZjR82jKfWog-jc=.686bee8b-e232-45e8-af43-254c9be0efc2@github.com>

On Thu, 24 Mar 2022 16:59:40 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Missed CommandLine.parse call in JextractTool.run method.

Looks good - we should probably add a test for this, using tool provider

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

Marked as reviewed by mcimadamore (Committer).

PR: https://git.openjdk.java.net/jextract/pull/4

From sundar at openjdk.java.net  Fri Mar 25 04:45:43 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Fri, 25 Mar 2022 04:45:43 GMT
Subject: RFR: 7903129: jextract does not handle @argfile [v2]
In-Reply-To: <xC5RHMobFybJDLHXjL6dGu_2avmxX5VfX0FXdZr440U=.91a2273e-1d5a-4f1e-8cc1-78f6acbbf326@github.com>
References: <xC5RHMobFybJDLHXjL6dGu_2avmxX5VfX0FXdZr440U=.91a2273e-1d5a-4f1e-8cc1-78f6acbbf326@github.com>
Message-ID: <BSbkze1-xjY5tShdkuLfXToUr3V9u4fghahGO1Uh7EQ=.d255b4e0-9ab0-4d7e-9797-2205a0f35ebd@github.com>

> Missed CommandLine.parse call in JextractTool.run method.

Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:

  adding test for @argfile

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/4/files
  - new: https://git.openjdk.java.net/jextract/pull/4/files/b0d4e0a0..9f4cf3c6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=4&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=4&range=00-01

  Stats: 22 lines in 1 file changed: 22 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jextract/pull/4.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/4/head:pull/4

PR: https://git.openjdk.java.net/jextract/pull/4

From sundar at openjdk.java.net  Fri Mar 25 05:52:44 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Fri, 25 Mar 2022 05:52:44 GMT
Subject: RFR: 7903129: jextract does not handle @argfile [v3]
In-Reply-To: <xC5RHMobFybJDLHXjL6dGu_2avmxX5VfX0FXdZr440U=.91a2273e-1d5a-4f1e-8cc1-78f6acbbf326@github.com>
References: <xC5RHMobFybJDLHXjL6dGu_2avmxX5VfX0FXdZr440U=.91a2273e-1d5a-4f1e-8cc1-78f6acbbf326@github.com>
Message-ID: <Z4iQ30xX3SdAX_xtkcTniT6-xFWrnHC9PCwSU06iPVI=.702592b2-1d82-4b31-8e2d-368730b0c96c@github.com>

> Missed CommandLine.parse call in JextractTool.run method.

Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:

  forgot to add helloargs

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/4/files
  - new: https://git.openjdk.java.net/jextract/pull/4/files/9f4cf3c6..950cb6b1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=4&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=4&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jextract/pull/4.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/4/head:pull/4

PR: https://git.openjdk.java.net/jextract/pull/4

From mcimadamore at openjdk.java.net  Fri Mar 25 10:46:08 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 25 Mar 2022 10:46:08 GMT
Subject: RFR: 7903129: jextract does not handle @argfile [v3]
In-Reply-To: <Z4iQ30xX3SdAX_xtkcTniT6-xFWrnHC9PCwSU06iPVI=.702592b2-1d82-4b31-8e2d-368730b0c96c@github.com>
References: <xC5RHMobFybJDLHXjL6dGu_2avmxX5VfX0FXdZr440U=.91a2273e-1d5a-4f1e-8cc1-78f6acbbf326@github.com>
 <Z4iQ30xX3SdAX_xtkcTniT6-xFWrnHC9PCwSU06iPVI=.702592b2-1d82-4b31-8e2d-368730b0c96c@github.com>
Message-ID: <6Pq_aPzvoqmls61JKG1ICuCXZlyJAP64tKup07C8-yQ=.2db307b0-0e1c-4aa9-bb2c-6fc7dee5513e@github.com>

On Fri, 25 Mar 2022 05:52:44 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> Missed CommandLine.parse call in JextractTool.run method.
>
> Athijegannathan Sundararajan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   forgot to add helloargs

Marked as reviewed by mcimadamore (Committer).

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

PR: https://git.openjdk.java.net/jextract/pull/4

From sundar at openjdk.java.net  Fri Mar 25 10:46:10 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Fri, 25 Mar 2022 10:46:10 GMT
Subject: Integrated: 7903129: jextract does not handle @argfile
In-Reply-To: <xC5RHMobFybJDLHXjL6dGu_2avmxX5VfX0FXdZr440U=.91a2273e-1d5a-4f1e-8cc1-78f6acbbf326@github.com>
References: <xC5RHMobFybJDLHXjL6dGu_2avmxX5VfX0FXdZr440U=.91a2273e-1d5a-4f1e-8cc1-78f6acbbf326@github.com>
Message-ID: <ZBGMP76QNZwzQCI6BAgfO2n6yTQtOoQQDTdYyf6kSrA=.1c619340-568b-4310-96ec-d5393ccd2696@github.com>

On Thu, 24 Mar 2022 16:59:40 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Missed CommandLine.parse call in JextractTool.run method.

This pull request has now been integrated.

Changeset: 60978d2f
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jextract/commit/60978d2fa669faca0249df120dc4a55d15cdff97
Stats:     36 lines in 4 files changed: 36 ins; 0 del; 0 mod

7903129: jextract does not handle @argfile

Reviewed-by: mcimadamore

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

PR: https://git.openjdk.java.net/jextract/pull/4

From sundararajan.athijegannathan at oracle.com  Fri Mar 25 10:51:11 2022
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Fri, 25 Mar 2022 10:51:11 +0000
Subject: Integrated: 7903129: jextract does not handle @argfile
In-Reply-To: <ZBGMP76QNZwzQCI6BAgfO2n6yTQtOoQQDTdYyf6kSrA=.1c619340-568b-4310-96ec-d5393ccd2696@github.com>
References: <xC5RHMobFybJDLHXjL6dGu_2avmxX5VfX0FXdZr440U=.91a2273e-1d5a-4f1e-8cc1-78f6acbbf326@github.com>
 <ZBGMP76QNZwzQCI6BAgfO2n6yTQtOoQQDTdYyf6kSrA=.1c619340-568b-4310-96ec-d5393ccd2696@github.com>
Message-ID: <MWHPR10MB1854CBBEBF9EF028502BE486EA1A9@MWHPR10MB1854.namprd10.prod.outlook.com>

Hi,

Fix has been integrated.

Please check @argfile support.

Thanks for reporting this issue,
-Sundar
________________________________
From: jextract-dev <jextract-dev-retn at openjdk.java.net> on behalf of Athijegannathan Sundararajan <sundar at openjdk.java.net>
Sent: 25 March 2022 16:16
To: jextract-dev at openjdk.java.net <jextract-dev at openjdk.java.net>
Subject: Integrated: 7903129: jextract does not handle @argfile

On Thu, 24 Mar 2022 16:59:40 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Missed CommandLine.parse call in JextractTool.run method.

This pull request has now been integrated.

Changeset: 60978d2f
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jextract/commit/60978d2fa669faca0249df120dc4a55d15cdff97
Stats:     36 lines in 4 files changed: 36 ins; 0 del; 0 mod

7903129: jextract does not handle @argfile

Reviewed-by: mcimadamore

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

PR: https://git.openjdk.java.net/jextract/pull/4

From jvernee at openjdk.java.net  Fri Mar 25 15:22:32 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 25 Mar 2022 15:22:32 GMT
Subject: RFR: Testing GHA
Message-ID: <OX_sp1R62QIyLmrLanHNZv4IRhIregZW8ChTvukgtRY=.245dfd5b-0eb8-4c02-bc65-8a92d8c37ebf@github.com>

Add a basic actions workflow that runs the tests on pull requests

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

Commit messages:
 - Use Oracle JDK
 - Back to repo hosted acitons
 - Update test.yml
 - Change actions to run in fork instead
 - Remove java check from test run
 - Typo
 - Add missing blank lines
 - Checkout specific jtreg tag
 - Working Impl
 - Remove whitespace
 - ... and 2 more: https://git.openjdk.java.net/jextract/compare/e6345e3a...c3d97f9a

Changes: https://git.openjdk.java.net/jextract/pull/6/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jextract&pr=6&range=00
  Stats: 64 lines in 1 file changed: 64 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jextract/pull/6.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/6/head:pull/6

PR: https://git.openjdk.java.net/jextract/pull/6

From jvernee at openjdk.java.net  Fri Mar 25 15:31:50 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 25 Mar 2022 15:31:50 GMT
Subject: RFR: Testing GHA [v2]
In-Reply-To: <OX_sp1R62QIyLmrLanHNZv4IRhIregZW8ChTvukgtRY=.245dfd5b-0eb8-4c02-bc65-8a92d8c37ebf@github.com>
References: <OX_sp1R62QIyLmrLanHNZv4IRhIregZW8ChTvukgtRY=.245dfd5b-0eb8-4c02-bc65-8a92d8c37ebf@github.com>
Message-ID: <X-DE8XjmJ-rXy6-ZcENEY3RhW1rNiEWLQTiFbmXdkAw=.b5f7a735-9efc-44a2-8920-234b77fa007f@github.com>

> Add a basic actions workflow that runs the tests on pull requests

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Tweak capitalisation

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/6/files
  - new: https://git.openjdk.java.net/jextract/pull/6/files/c3d97f9a..7cac234f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=6&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=6&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jextract/pull/6.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/6/head:pull/6

PR: https://git.openjdk.java.net/jextract/pull/6

From mcimadamore at openjdk.java.net  Fri Mar 25 15:53:59 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 25 Mar 2022 15:53:59 GMT
Subject: RFR: Testing GHA [v2]
In-Reply-To: <X-DE8XjmJ-rXy6-ZcENEY3RhW1rNiEWLQTiFbmXdkAw=.b5f7a735-9efc-44a2-8920-234b77fa007f@github.com>
References: <OX_sp1R62QIyLmrLanHNZv4IRhIregZW8ChTvukgtRY=.245dfd5b-0eb8-4c02-bc65-8a92d8c37ebf@github.com>
 <X-DE8XjmJ-rXy6-ZcENEY3RhW1rNiEWLQTiFbmXdkAw=.b5f7a735-9efc-44a2-8920-234b77fa007f@github.com>
Message-ID: <WHgVpB1Y6rHOs5rVBVgFhKlLzfeouPjHvHUTUo_VnAg=.122b689a-2b34-4931-a2ce-eb2b500c32eb@github.com>

On Fri, 25 Mar 2022 15:31:50 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Add a basic actions workflow that runs the tests on pull requests
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak capitalisation

.github/workflows/test.yml line 14:

> 12: 
> 13:   linux-x64:
> 14:     runs-on: ubuntu-latest

since you are downloading Ubuntu 18.04 binaries, wouldn't it be better to use 18.04 here? Also, 18.04 is a bit on the old side - wouldn't 20.04 be better?

https://github.com/llvm/llvm-project/releases/download/llvmorg-13.0.0/clang+llvm-13.0.0-x86_64-linux-gnu-ubuntu-20.04.tar.xz

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

PR: https://git.openjdk.java.net/jextract/pull/6

From jvernee at openjdk.java.net  Fri Mar 25 16:02:09 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 25 Mar 2022 16:02:09 GMT
Subject: RFR: Testing GHA [v2]
In-Reply-To: <WHgVpB1Y6rHOs5rVBVgFhKlLzfeouPjHvHUTUo_VnAg=.122b689a-2b34-4931-a2ce-eb2b500c32eb@github.com>
References: <OX_sp1R62QIyLmrLanHNZv4IRhIregZW8ChTvukgtRY=.245dfd5b-0eb8-4c02-bc65-8a92d8c37ebf@github.com>
 <X-DE8XjmJ-rXy6-ZcENEY3RhW1rNiEWLQTiFbmXdkAw=.b5f7a735-9efc-44a2-8920-234b77fa007f@github.com>
 <WHgVpB1Y6rHOs5rVBVgFhKlLzfeouPjHvHUTUo_VnAg=.122b689a-2b34-4931-a2ce-eb2b500c32eb@github.com>
Message-ID: <TE-zXrc_OtY6ITcTCRBI4gdNyxGds2mThAOIdVVt0SY=.9480d1d0-5305-482d-b55d-f15934658339@github.com>

On Fri, 25 Mar 2022 15:49:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak capitalisation
>
> .github/workflows/test.yml line 14:
> 
>> 12: 
>> 13:   linux-x64:
>> 14:     runs-on: ubuntu-latest
> 
> since you are downloading Ubuntu 18.04 binaries, wouldn't it be better to use 18.04 here? Also, 18.04 is a bit on the old side - wouldn't 20.04 be better?
> 
> https://github.com/llvm/llvm-project/releases/download/llvmorg-13.0.0/clang+llvm-13.0.0-x86_64-linux-gnu-ubuntu-20.04.tar.xz

Hmm, okay. I'll use that binary instead. There was no package for 20.04 for LLVM 13.0.1

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

PR: https://git.openjdk.java.net/jextract/pull/6

From jvernee at openjdk.java.net  Fri Mar 25 16:17:18 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 25 Mar 2022 16:17:18 GMT
Subject: RFR: Testing GHA [v3]
In-Reply-To: <OX_sp1R62QIyLmrLanHNZv4IRhIregZW8ChTvukgtRY=.245dfd5b-0eb8-4c02-bc65-8a92d8c37ebf@github.com>
References: <OX_sp1R62QIyLmrLanHNZv4IRhIregZW8ChTvukgtRY=.245dfd5b-0eb8-4c02-bc65-8a92d8c37ebf@github.com>
Message-ID: <3xCiKWIJ3uWl6AgCdOOna-ENum99pe6B1P1QQk_7pp4=.31a2975c-5426-4a50-89c0-fc2a7f0a2732@github.com>

> Add a basic actions workflow that runs the tests on pull requests

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Change used LLVM binary to version specifically for Ubuntu 20.04

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/6/files
  - new: https://git.openjdk.java.net/jextract/pull/6/files/7cac234f..998e2adc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=6&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=6&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jextract/pull/6.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/6/head:pull/6

PR: https://git.openjdk.java.net/jextract/pull/6

From sundar at openjdk.java.net  Fri Mar 25 16:22:22 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Fri, 25 Mar 2022 16:22:22 GMT
Subject: RFR: 7903133: add lp_solve sample
Message-ID: <UMRtLDyDTBKsr9g4-T41KDqTjkAILkIz9qektMu6GS0=.36d15052-8594-4757-b77e-d97f8ba5c822@github.com>

Adding lp_solve jextract sample. This is more or less straight port of a C example.

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

Commit messages:
 - removed trailing whitespaces in LpSolveDemo.java
 - 7903133: add lp_solve sample

Changes: https://git.openjdk.java.net/jextract/pull/7/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jextract&pr=7&range=00
  Issue: https://bugs.openjdk.java.net/browse/CODETOOLS-7903133
  Stats: 166 lines in 7 files changed: 166 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jextract/pull/7.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/7/head:pull/7

PR: https://git.openjdk.java.net/jextract/pull/7

From duke at openjdk.java.net  Fri Mar 25 16:22:34 2022
From: duke at openjdk.java.net (Ethan McCue)
Date: Fri, 25 Mar 2022 16:22:34 GMT
Subject: RFR: 7903132: Replace casts with type test pattern
Message-ID: <mdEDtqpZUigsk9HMSgsvbAC18VDpmi__EHfWxe_vNDU=.b7f55c58-a529-40bd-b02a-58f8cb78b1f0@github.com>

Replaces a handful of casts following type tests with the equivalent pattern syntax.

I cannot create a matching issue, as I do not have an account on the bug tracker.

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

Commit messages:
 - Replace casts with type test pattern

Changes: https://git.openjdk.java.net/jextract/pull/5/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jextract&pr=5&range=00
  Issue: https://bugs.openjdk.java.net/browse/CODETOOLS-7903132
  Stats: 81 lines in 13 files changed: 2 ins; 22 del; 57 mod
  Patch: https://git.openjdk.java.net/jextract/pull/5.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/5/head:pull/5

PR: https://git.openjdk.java.net/jextract/pull/5

From mcimadamore at openjdk.java.net  Fri Mar 25 16:22:34 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 25 Mar 2022 16:22:34 GMT
Subject: RFR: 7903132: Replace casts with type test pattern
In-Reply-To: <mdEDtqpZUigsk9HMSgsvbAC18VDpmi__EHfWxe_vNDU=.b7f55c58-a529-40bd-b02a-58f8cb78b1f0@github.com>
References: <mdEDtqpZUigsk9HMSgsvbAC18VDpmi__EHfWxe_vNDU=.b7f55c58-a529-40bd-b02a-58f8cb78b1f0@github.com>
Message-ID: <BuR2VkE6FGhE2rDslbE0mNNeAf9zvW7BVOXjG2fwkp4=.59371344-8704-43ea-b918-507676794233@github.com>

On Thu, 24 Mar 2022 22:48:41 GMT, Ethan McCue <duke at openjdk.java.net> wrote:

> Replaces a handful of casts following type tests with the equivalent pattern syntax.
> 
> I cannot create a matching issue, as I do not have an account on the bug tracker.

Are you in a position to file a JBS issue for this? We're happy to sponsor - the problem here is that the subject of the PR has to be in the form:

NNNNNNN: <JBS issue subject>

For it to go through. If you are having issues, please let us know and we'll try to find an alternate arrangement.

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

PR: https://git.openjdk.java.net/jextract/pull/5

From duke at openjdk.java.net  Fri Mar 25 16:22:34 2022
From: duke at openjdk.java.net (Ethan McCue)
Date: Fri, 25 Mar 2022 16:22:34 GMT
Subject: RFR: 7903132: Replace casts with type test pattern
In-Reply-To: <mdEDtqpZUigsk9HMSgsvbAC18VDpmi__EHfWxe_vNDU=.b7f55c58-a529-40bd-b02a-58f8cb78b1f0@github.com>
References: <mdEDtqpZUigsk9HMSgsvbAC18VDpmi__EHfWxe_vNDU=.b7f55c58-a529-40bd-b02a-58f8cb78b1f0@github.com>
Message-ID: <UiRpADqHTuAtAPQlAzmV6kT3PlgI2AiGkrp27MfFuhg=.ea3b391f-1c6b-460a-afe0-d3f45a018dc8@github.com>

On Thu, 24 Mar 2022 22:48:41 GMT, Ethan McCue <duke at openjdk.java.net> wrote:

> Replaces a handful of casts following type tests with the equivalent pattern syntax.
> 
> I cannot create a matching issue, as I do not have an account on the bug tracker.

My understanding is that I can't file a JBS issue until I get an account, which only happens after having made two contributions and petitioning for becoming an author.

I can do it the long way around certainly by filing a bug report via the oracle site, but I don't think this is the sort of thing that would make it past that filter.

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

PR: https://git.openjdk.java.net/jextract/pull/5

From jvernee at openjdk.java.net  Fri Mar 25 16:22:35 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 25 Mar 2022 16:22:35 GMT
Subject: RFR: 7903132: Replace casts with type test pattern
In-Reply-To: <mdEDtqpZUigsk9HMSgsvbAC18VDpmi__EHfWxe_vNDU=.b7f55c58-a529-40bd-b02a-58f8cb78b1f0@github.com>
References: <mdEDtqpZUigsk9HMSgsvbAC18VDpmi__EHfWxe_vNDU=.b7f55c58-a529-40bd-b02a-58f8cb78b1f0@github.com>
Message-ID: <mTZDIfyojw2h-EGs0cJP714hYQ7_Z_LU_ky4bvauGpg=.b4f66469-733e-4416-8c09-0335786bb56e@github.com>

On Thu, 24 Mar 2022 22:48:41 GMT, Ethan McCue <duke at openjdk.java.net> wrote:

> Replaces a handful of casts following type tests with the equivalent pattern syntax.
> 
> I cannot create a matching issue, as I do not have an account on the bug tracker.

I've filed an issue for this PR here: https://bugs.openjdk.java.net/browse/CODETOOLS-7903132 Please update the PR title to include the issue number.

src/main/java/org/openjdk/jextract/clang/Cursor.java line 243:

> 241:             return false;
> 242:         }
> 243:         return (Index_h.clang_equalCursors(cursor, otherCursor.cursor) != 0);

I think in these cases we can do better by merging the `instanceof` check above this in the condition. i.e.
Suggestion:

        return other instanceof Cursor otherCursor
            && (Index_h.clang_equalCursors(cursor, otherCursor.cursor) != 0);


And similar for other places that are computing a boolean value, such as all the equals methods.

src/main/java/org/openjdk/jextract/impl/ClassSourceBuilder.java line 59:

> 57:     ClassSourceBuilder(JavaSourceBuilder enclosing, Kind kind, String name) {
> 58:         this.enclosing = enclosing;
> 59:         this.align = (enclosing instanceof ClassSourceBuilder enclosing) ? enclosing.align : 0;

This is resulting in a compilation error:

jextract\src\main\java\org\openjdk\jextract\impl\ClassSourceBuilder.java:59: error: variable enclosing is already defined in constructor ClassSourceBuilder(JavaSourceBuilder,Kind,String)
        this.align = (enclosing instanceof ClassSourceBuilder enclosing) ? enclosing.align : 0;

Please build and test the patch locally on your machine as well, if you haven't done so already. (This should be done before suggesting changes).

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

PR: https://git.openjdk.java.net/jextract/pull/5

From duke at openjdk.java.net  Fri Mar 25 16:22:35 2022
From: duke at openjdk.java.net (Ethan McCue)
Date: Fri, 25 Mar 2022 16:22:35 GMT
Subject: RFR: 7903132: Replace casts with type test pattern
In-Reply-To: <mTZDIfyojw2h-EGs0cJP714hYQ7_Z_LU_ky4bvauGpg=.b4f66469-733e-4416-8c09-0335786bb56e@github.com>
References: <mdEDtqpZUigsk9HMSgsvbAC18VDpmi__EHfWxe_vNDU=.b7f55c58-a529-40bd-b02a-58f8cb78b1f0@github.com>
 <mTZDIfyojw2h-EGs0cJP714hYQ7_Z_LU_ky4bvauGpg=.b4f66469-733e-4416-8c09-0335786bb56e@github.com>
Message-ID: <IBa0KU2JwX8WUclxkO238NSdWtd88Y0_zLGT7oId9a0=.e82a8a0f-37ae-4dc4-97da-6cec284966af@github.com>

On Fri, 25 Mar 2022 15:04:05 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Replaces a handful of casts following type tests with the equivalent pattern syntax.
>> 
>> I cannot create a matching issue, as I do not have an account on the bug tracker.
>
> src/main/java/org/openjdk/jextract/clang/Cursor.java line 243:
> 
>> 241:             return false;
>> 242:         }
>> 243:         return (Index_h.clang_equalCursors(cursor, otherCursor.cursor) != 0);
> 
> I think in these cases we can do better by merging the `instanceof` check above this in the condition. i.e.
> Suggestion:
> 
>         return other instanceof Cursor otherCursor
>             && (Index_h.clang_equalCursors(cursor, otherCursor.cursor) != 0);
> 
> 
> And similar for other places that are computing a boolean value, such as all the equals methods.

Strictly speaking, the whole method body could be merged into one expression. Its the realm of infinite bikesheds though, and I did not / do not know if there is a set of implicit style choices there.

> src/main/java/org/openjdk/jextract/impl/ClassSourceBuilder.java line 59:
> 
>> 57:     ClassSourceBuilder(JavaSourceBuilder enclosing, Kind kind, String name) {
>> 58:         this.enclosing = enclosing;
>> 59:         this.align = (enclosing instanceof ClassSourceBuilder enclosing) ? enclosing.align : 0;
> 
> This is resulting in a compilation error:
> 
> jextract\src\main\java\org\openjdk\jextract\impl\ClassSourceBuilder.java:59: error: variable enclosing is already defined in constructor ClassSourceBuilder(JavaSourceBuilder,Kind,String)
>         this.align = (enclosing instanceof ClassSourceBuilder enclosing) ? enclosing.align : 0;
> 
> Please build and test the patch locally on your machine as well, if you haven't done so already. (This should be done before suggesting changes).

So yes, 100% on me. But in my defense I am getting a particularly obtuse error before compilation and there isn't exactly someone to ask without pretense.


$ /usr/bin/clang --version
Apple clang version 13.1.6 (clang-1316.0.21.2)
Target: arm64-apple-darwin21.3.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

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

$ sh ./gradlew -Pjdk18_home=/Users/emccue/Library/Java/JavaVirtualMachines/openjdk-18/Contents/Home  clean verify

FAILURE: Build failed with an exception.

* Where:
Build file '/Users/emccue/Development/jextract/build.gradle' line: 13

* What went wrong:
A problem occurred evaluating root project 'jextract'.
> Could not get unknown property 'libclang_home' for root project 'jextract' of type org.gradle.api.Project.

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 297ms

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

$ sh ./gradlew -Pjdk18_home=/Users/emccue/Library/Java/JavaVirtualMachines/openjdk-18/Contents/Home -Plibclang_home=/usr/bin/clang clean verify

FAILURE: Build failed with an exception.

* Where:
Build file '/Users/emccue/Development/jextract/build.gradle' line: 14

* What went wrong:
A problem occurred evaluating root project 'jextract'.
> Cannot invoke method getAt() on null object

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 287ms

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

$ sh ./gradlew -Pjdk18_home=/Users/emccue/Library/Java/JavaVirtualMachines/openjdk-18/Contents/Home -Plibclang_home=/usr/bin/ clean verify

FAILURE: Build failed with an exception.

* Where:
Build file '/Users/emccue/Development/jextract/build.gradle' line: 14

* What went wrong:
A problem occurred evaluating root project 'jextract'.
> Cannot invoke method getAt() on null object

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 290ms

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

PR: https://git.openjdk.java.net/jextract/pull/5

From jvernee at openjdk.java.net  Fri Mar 25 16:22:35 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 25 Mar 2022 16:22:35 GMT
Subject: RFR: 7903132: Replace casts with type test pattern
In-Reply-To: <IBa0KU2JwX8WUclxkO238NSdWtd88Y0_zLGT7oId9a0=.e82a8a0f-37ae-4dc4-97da-6cec284966af@github.com>
References: <mdEDtqpZUigsk9HMSgsvbAC18VDpmi__EHfWxe_vNDU=.b7f55c58-a529-40bd-b02a-58f8cb78b1f0@github.com>
 <mTZDIfyojw2h-EGs0cJP714hYQ7_Z_LU_ky4bvauGpg=.b4f66469-733e-4416-8c09-0335786bb56e@github.com>
 <IBa0KU2JwX8WUclxkO238NSdWtd88Y0_zLGT7oId9a0=.e82a8a0f-37ae-4dc4-97da-6cec284966af@github.com>
Message-ID: <qLgQ2AAT7wC51AsGKUPmurF3eYd8DF53oXn5j8gHRio=.594fb1af-4111-409e-aaa9-bedca42c1e22@github.com>

On Fri, 25 Mar 2022 15:39:18 GMT, Ethan McCue <duke at openjdk.java.net> wrote:

>> src/main/java/org/openjdk/jextract/clang/Cursor.java line 243:
>> 
>>> 241:             return false;
>>> 242:         }
>>> 243:         return (Index_h.clang_equalCursors(cursor, otherCursor.cursor) != 0);
>> 
>> I think in these cases we can do better by merging the `instanceof` check above this in the condition. i.e.
>> Suggestion:
>> 
>>         return other instanceof Cursor otherCursor
>>             && (Index_h.clang_equalCursors(cursor, otherCursor.cursor) != 0);
>> 
>> 
>> And similar for other places that are computing a boolean value, such as all the equals methods.
>
> Strictly speaking, the whole method body could be merged into one expression. Its the realm of infinite bikesheds though, and I did not / do not know if there is a set of implicit style choices there.

Well, we're on the topic of style changes already, so let's pull the string. This is new territory, so I think this is where we decide this :)

Merging the `instanceof` into the expression avoids having the pattern variable be carried over to outside of the `if` block, which I think is better.

The `this == other` check above that doesn't have the same problem.

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

PR: https://git.openjdk.java.net/jextract/pull/5

From duke at openjdk.java.net  Fri Mar 25 16:22:36 2022
From: duke at openjdk.java.net (Ethan McCue)
Date: Fri, 25 Mar 2022 16:22:36 GMT
Subject: RFR: 7903132: Replace casts with type test pattern
In-Reply-To: <IBa0KU2JwX8WUclxkO238NSdWtd88Y0_zLGT7oId9a0=.e82a8a0f-37ae-4dc4-97da-6cec284966af@github.com>
References: <mdEDtqpZUigsk9HMSgsvbAC18VDpmi__EHfWxe_vNDU=.b7f55c58-a529-40bd-b02a-58f8cb78b1f0@github.com>
 <mTZDIfyojw2h-EGs0cJP714hYQ7_Z_LU_ky4bvauGpg=.b4f66469-733e-4416-8c09-0335786bb56e@github.com>
 <IBa0KU2JwX8WUclxkO238NSdWtd88Y0_zLGT7oId9a0=.e82a8a0f-37ae-4dc4-97da-6cec284966af@github.com>
Message-ID: <CsC9ALCOc6JZchd_bK_cCwVoqUK1VqJeS84jgxch8tw=.5a28341d-df52-420d-9188-aacdcdce4e29@github.com>

On Fri, 25 Mar 2022 15:35:43 GMT, Ethan McCue <duke at openjdk.java.net> wrote:

>> src/main/java/org/openjdk/jextract/impl/ClassSourceBuilder.java line 59:
>> 
>>> 57:     ClassSourceBuilder(JavaSourceBuilder enclosing, Kind kind, String name) {
>>> 58:         this.enclosing = enclosing;
>>> 59:         this.align = (enclosing instanceof ClassSourceBuilder enclosing) ? enclosing.align : 0;
>> 
>> This is resulting in a compilation error:
>> 
>> jextract\src\main\java\org\openjdk\jextract\impl\ClassSourceBuilder.java:59: error: variable enclosing is already defined in constructor ClassSourceBuilder(JavaSourceBuilder,Kind,String)
>>         this.align = (enclosing instanceof ClassSourceBuilder enclosing) ? enclosing.align : 0;
>> 
>> Please build and test the patch locally on your machine as well, if you haven't done so already. (This should be done before suggesting changes).
>
> So yes, 100% on me. But in my defense I am getting a particularly obtuse error before compilation and there isn't exactly someone to ask without pretense.
> 
> 
> $ /usr/bin/clang --version
> Apple clang version 13.1.6 (clang-1316.0.21.2)
> Target: arm64-apple-darwin21.3.0
> Thread model: posix
> InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
> 
> ---------------------
> 
> $ sh ./gradlew -Pjdk18_home=/Users/emccue/Library/Java/JavaVirtualMachines/openjdk-18/Contents/Home  clean verify
> 
> FAILURE: Build failed with an exception.
> 
> * Where:
> Build file '/Users/emccue/Development/jextract/build.gradle' line: 13
> 
> * What went wrong:
> A problem occurred evaluating root project 'jextract'.
>> Could not get unknown property 'libclang_home' for root project 'jextract' of type org.gradle.api.Project.
> 
> * Try:
>> Run with --stacktrace option to get the stack trace.
>> Run with --info or --debug option to get more log output.
>> Run with --scan to get full insights.
> 
> * Get more help at https://help.gradle.org
> 
> BUILD FAILED in 297ms
> 
> ---------------------
> 
> $ sh ./gradlew -Pjdk18_home=/Users/emccue/Library/Java/JavaVirtualMachines/openjdk-18/Contents/Home -Plibclang_home=/usr/bin/clang clean verify
> 
> FAILURE: Build failed with an exception.
> 
> * Where:
> Build file '/Users/emccue/Development/jextract/build.gradle' line: 14
> 
> * What went wrong:
> A problem occurred evaluating root project 'jextract'.
>> Cannot invoke method getAt() on null object
> 
> * Try:
>> Run with --stacktrace option to get the stack trace.
>> Run with --info or --debug option to get more log output.
>> Run with --scan to get full insights.
> 
> * Get more help at https://help.gradle.org
> 
> BUILD FAILED in 287ms
> 
> ---------------------
> 
> $ sh ./gradlew -Pjdk18_home=/Users/emccue/Library/Java/JavaVirtualMachines/openjdk-18/Contents/Home -Plibclang_home=/usr/bin/ clean verify
> 
> FAILURE: Build failed with an exception.
> 
> * Where:
> Build file '/Users/emccue/Development/jextract/build.gradle' line: 14
> 
> * What went wrong:
> A problem occurred evaluating root project 'jextract'.
>> Cannot invoke method getAt() on null object
> 
> * Try:
>> Run with --stacktrace option to get the stack trace.
>> Run with --info or --debug option to get more log output.
>> Run with --scan to get full insights.
> 
> * Get more help at https://help.gradle.org
> 
> BUILD FAILED in 290ms

(I was counting on some CI/CD to be triggered on PR, which i suppose either isn't the case or isn't the case unless i get past the issue number check)

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

PR: https://git.openjdk.java.net/jextract/pull/5

From jvernee at openjdk.java.net  Fri Mar 25 16:22:36 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 25 Mar 2022 16:22:36 GMT
Subject: RFR: 7903132: Replace casts with type test pattern
In-Reply-To: <CsC9ALCOc6JZchd_bK_cCwVoqUK1VqJeS84jgxch8tw=.5a28341d-df52-420d-9188-aacdcdce4e29@github.com>
References: <mdEDtqpZUigsk9HMSgsvbAC18VDpmi__EHfWxe_vNDU=.b7f55c58-a529-40bd-b02a-58f8cb78b1f0@github.com>
 <mTZDIfyojw2h-EGs0cJP714hYQ7_Z_LU_ky4bvauGpg=.b4f66469-733e-4416-8c09-0335786bb56e@github.com>
 <IBa0KU2JwX8WUclxkO238NSdWtd88Y0_zLGT7oId9a0=.e82a8a0f-37ae-4dc4-97da-6cec284966af@github.com>
 <CsC9ALCOc6JZchd_bK_cCwVoqUK1VqJeS84jgxch8tw=.5a28341d-df52-420d-9188-aacdcdce4e29@github.com>
Message-ID: <z_e-B24GHsjIxdfL3Y9mfSOkOSoND7dtn6BEXeu2KzA=.83528885-3a1e-4f89-80ff-6c1a8bf0426d@github.com>

On Fri, 25 Mar 2022 15:40:21 GMT, Ethan McCue <duke at openjdk.java.net> wrote:

>> So yes, 100% on me. But in my defense I am getting a particularly obtuse error before compilation and there isn't exactly someone to ask without pretense.
>> 
>> 
>> $ /usr/bin/clang --version
>> Apple clang version 13.1.6 (clang-1316.0.21.2)
>> Target: arm64-apple-darwin21.3.0
>> Thread model: posix
>> InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>> 
>> ---------------------
>> 
>> $ sh ./gradlew -Pjdk18_home=/Users/emccue/Library/Java/JavaVirtualMachines/openjdk-18/Contents/Home  clean verify
>> 
>> FAILURE: Build failed with an exception.
>> 
>> * Where:
>> Build file '/Users/emccue/Development/jextract/build.gradle' line: 13
>> 
>> * What went wrong:
>> A problem occurred evaluating root project 'jextract'.
>>> Could not get unknown property 'libclang_home' for root project 'jextract' of type org.gradle.api.Project.
>> 
>> * Try:
>>> Run with --stacktrace option to get the stack trace.
>>> Run with --info or --debug option to get more log output.
>>> Run with --scan to get full insights.
>> 
>> * Get more help at https://help.gradle.org
>> 
>> BUILD FAILED in 297ms
>> 
>> ---------------------
>> 
>> $ sh ./gradlew -Pjdk18_home=/Users/emccue/Library/Java/JavaVirtualMachines/openjdk-18/Contents/Home -Plibclang_home=/usr/bin/clang clean verify
>> 
>> FAILURE: Build failed with an exception.
>> 
>> * Where:
>> Build file '/Users/emccue/Development/jextract/build.gradle' line: 14
>> 
>> * What went wrong:
>> A problem occurred evaluating root project 'jextract'.
>>> Cannot invoke method getAt() on null object
>> 
>> * Try:
>>> Run with --stacktrace option to get the stack trace.
>>> Run with --info or --debug option to get more log output.
>>> Run with --scan to get full insights.
>> 
>> * Get more help at https://help.gradle.org
>> 
>> BUILD FAILED in 287ms
>> 
>> ---------------------
>> 
>> $ sh ./gradlew -Pjdk18_home=/Users/emccue/Library/Java/JavaVirtualMachines/openjdk-18/Contents/Home -Plibclang_home=/usr/bin/ clean verify
>> 
>> FAILURE: Build failed with an exception.
>> 
>> * Where:
>> Build file '/Users/emccue/Development/jextract/build.gradle' line: 14
>> 
>> * What went wrong:
>> A problem occurred evaluating root project 'jextract'.
>>> Cannot invoke method getAt() on null object
>> 
>> * Try:
>>> Run with --stacktrace option to get the stack trace.
>>> Run with --info or --debug option to get more log output.
>>> Run with --scan to get full insights.
>> 
>> * Get more help at https://help.gradle.org
>> 
>> BUILD FAILED in 290ms
>
> (I was counting on some CI/CD to be triggered on PR, which i suppose either isn't the case or isn't the case unless i get past the issue number check)

Questions can be directed at the mailing list (either jextract-dev at openjdk.java.net or panama-dev at openjdk.java.net). You can send an email there without making an account as well (it will go through a moderation queue first).

I agree the error message is not great. In this case the issue seems to be this line in build.gradle:


def clang_version = new File("${libclang_home}/lib/clang/").list()[0]


i.e. the `libclang_home` directory does not have the expected directory structure. It is looking for a directory like `<libclang_home>/lib/clang/<VERSION>`. So please make sure that exists.

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

PR: https://git.openjdk.java.net/jextract/pull/5

From jvernee at openjdk.java.net  Fri Mar 25 16:23:28 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 25 Mar 2022 16:23:28 GMT
Subject: RFR: 7903134: Imrpove error reporting in jextract gradle build
Message-ID: <UGNQ6THETKMxmQZ1_qXET__r1VD9FqicdqJCQJ0of0Q=.17cb2bb7-5933-4113-a0f6-6492f9307e8c@github.com>

Improve error reporting around missing LLVM paths in jextract gradle build.

This patch tries to detect missing paths and throw a descriptive error, instead of a more cryptic one.

I've also added the `.idea` folder to the `.gitignore` file.

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

Commit messages:
 - ignore .idea folder
 - Improve error reporting around missing LLVM paths in the gradle build.

Changes: https://git.openjdk.java.net/jextract/pull/8/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jextract&pr=8&range=00
  Issue: https://bugs.openjdk.java.net/browse/CODETOOLS-7903134
  Stats: 19 lines in 2 files changed: 18 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jextract/pull/8.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/8/head:pull/8

PR: https://git.openjdk.java.net/jextract/pull/8

From mcimadamore at openjdk.java.net  Fri Mar 25 17:06:06 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 25 Mar 2022 17:06:06 GMT
Subject: RFR: Testing GHA [v2]
In-Reply-To: <TE-zXrc_OtY6ITcTCRBI4gdNyxGds2mThAOIdVVt0SY=.9480d1d0-5305-482d-b55d-f15934658339@github.com>
References: <OX_sp1R62QIyLmrLanHNZv4IRhIregZW8ChTvukgtRY=.245dfd5b-0eb8-4c02-bc65-8a92d8c37ebf@github.com>
 <X-DE8XjmJ-rXy6-ZcENEY3RhW1rNiEWLQTiFbmXdkAw=.b5f7a735-9efc-44a2-8920-234b77fa007f@github.com>
 <WHgVpB1Y6rHOs5rVBVgFhKlLzfeouPjHvHUTUo_VnAg=.122b689a-2b34-4931-a2ce-eb2b500c32eb@github.com>
 <TE-zXrc_OtY6ITcTCRBI4gdNyxGds2mThAOIdVVt0SY=.9480d1d0-5305-482d-b55d-f15934658339@github.com>
Message-ID: <nxSlAcuYrE2_UO11fQbmJvA64X5KXABjmCRii5Gjb_U=.06f8ee2d-2628-4a90-830b-ca81e0986554@github.com>

On Fri, 25 Mar 2022 15:58:45 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> .github/workflows/test.yml line 14:
>> 
>>> 12: 
>>> 13:   linux-x64:
>>> 14:     runs-on: ubuntu-latest
>> 
>> since you are downloading Ubuntu 18.04 binaries, wouldn't it be better to use 18.04 here? Also, 18.04 is a bit on the old side - wouldn't 20.04 be better?
>> 
>> https://github.com/llvm/llvm-project/releases/download/llvmorg-13.0.0/clang+llvm-13.0.0-x86_64-linux-gnu-ubuntu-20.04.tar.xz
>
> Hmm, okay. I'll use that binary instead. There was no package for 20.04 for LLVM 13.0.1

will not this break when `ubuntu-latest` binds to 22.04? Can we specify a specific ubuntu version?

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

PR: https://git.openjdk.java.net/jextract/pull/6

From mcimadamore at openjdk.java.net  Fri Mar 25 17:07:05 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 25 Mar 2022 17:07:05 GMT
Subject: RFR: 7903133: add lp_solve sample
In-Reply-To: <UMRtLDyDTBKsr9g4-T41KDqTjkAILkIz9qektMu6GS0=.36d15052-8594-4757-b77e-d97f8ba5c822@github.com>
References: <UMRtLDyDTBKsr9g4-T41KDqTjkAILkIz9qektMu6GS0=.36d15052-8594-4757-b77e-d97f8ba5c822@github.com>
Message-ID: <LUtT31vyBXlhmyy8_KuXGfNN3ad-Egmzcy3W2uxaaNA=.3136285a-47bc-4148-9b7f-4e4475fefc8d@github.com>

On Fri, 25 Mar 2022 15:48:41 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Adding lp_solve jextract sample. This is more or less straight port of a C example.

Marked as reviewed by mcimadamore (Committer).

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

PR: https://git.openjdk.java.net/jextract/pull/7

From mcimadamore at openjdk.java.net  Fri Mar 25 17:17:09 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 25 Mar 2022 17:17:09 GMT
Subject: RFR: 7903134: Imrpove error reporting in jextract gradle build
In-Reply-To: <UGNQ6THETKMxmQZ1_qXET__r1VD9FqicdqJCQJ0of0Q=.17cb2bb7-5933-4113-a0f6-6492f9307e8c@github.com>
References: <UGNQ6THETKMxmQZ1_qXET__r1VD9FqicdqJCQJ0of0Q=.17cb2bb7-5933-4113-a0f6-6492f9307e8c@github.com>
Message-ID: <0wXoRA8GQ4MH0Od2IIbtumEUPp7HntPi4JjCQ6wR6pA=.4a81b3b3-c66a-465c-9146-90e547999610@github.com>

On Fri, 25 Mar 2022 16:16:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Improve error reporting around missing LLVM paths in jextract gradle build.
> 
> This patch tries to detect missing paths and throw a descriptive error, instead of a more cryptic one.
> 
> I've also added the `.idea` folder to the `.gitignore` file.

Looks good - should we take the change and also rename libclang_home to llvm_home?

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

PR: https://git.openjdk.java.net/jextract/pull/8

From jvernee at openjdk.java.net  Fri Mar 25 18:10:40 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 25 Mar 2022 18:10:40 GMT
Subject: RFR: 7903134: Improve error reporting in jextract gradle build
 [v2]
In-Reply-To: <UGNQ6THETKMxmQZ1_qXET__r1VD9FqicdqJCQJ0of0Q=.17cb2bb7-5933-4113-a0f6-6492f9307e8c@github.com>
References: <UGNQ6THETKMxmQZ1_qXET__r1VD9FqicdqJCQJ0of0Q=.17cb2bb7-5933-4113-a0f6-6492f9307e8c@github.com>
Message-ID: <-NoJHgjIRr-W3rWHvj-Bq9MNysbk6HS-VKns0Pm3FPY=.0b371332-3eb6-424c-9df9-cf3b4986d86d@github.com>

> Improve error reporting around missing LLVM paths in jextract gradle build.
> 
> This patch tries to detect missing paths and throw a descriptive error, instead of a more cryptic one.
> 
> I've also added the `.idea` folder to the `.gitignore` file.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  libclang_home -> llvm_home

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/8/files
  - new: https://git.openjdk.java.net/jextract/pull/8/files/2237d18b..203f888e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=8&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=8&range=00-01

  Stats: 9 lines in 2 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jextract/pull/8.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/8/head:pull/8

PR: https://git.openjdk.java.net/jextract/pull/8

From mcimadamore at openjdk.java.net  Fri Mar 25 18:10:40 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 25 Mar 2022 18:10:40 GMT
Subject: RFR: 7903134: Improve error reporting in jextract gradle build
 [v2]
In-Reply-To: <-NoJHgjIRr-W3rWHvj-Bq9MNysbk6HS-VKns0Pm3FPY=.0b371332-3eb6-424c-9df9-cf3b4986d86d@github.com>
References: <UGNQ6THETKMxmQZ1_qXET__r1VD9FqicdqJCQJ0of0Q=.17cb2bb7-5933-4113-a0f6-6492f9307e8c@github.com>
 <-NoJHgjIRr-W3rWHvj-Bq9MNysbk6HS-VKns0Pm3FPY=.0b371332-3eb6-424c-9df9-cf3b4986d86d@github.com>
Message-ID: <VoKKa-guKV50vv7TnyXlR7BirxVMoyitHwnWUFO6Y5s=.2ed450cf-cd9e-4025-bb58-06b2da450c8a@github.com>

On Fri, 25 Mar 2022 18:07:17 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Improve error reporting around missing LLVM paths in jextract gradle build.
>> 
>> This patch tries to detect missing paths and throw a descriptive error, instead of a more cryptic one.
>> 
>> I've also added the `.idea` folder to the `.gitignore` file.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   libclang_home -> llvm_home

Looks good, thanks!

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

Marked as reviewed by mcimadamore (Committer).

PR: https://git.openjdk.java.net/jextract/pull/8

From jvernee at openjdk.java.net  Fri Mar 25 18:10:42 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 25 Mar 2022 18:10:42 GMT
Subject: RFR: 7903134: Improve error reporting in jextract gradle build
 [v2]
In-Reply-To: <0wXoRA8GQ4MH0Od2IIbtumEUPp7HntPi4JjCQ6wR6pA=.4a81b3b3-c66a-465c-9146-90e547999610@github.com>
References: <UGNQ6THETKMxmQZ1_qXET__r1VD9FqicdqJCQJ0of0Q=.17cb2bb7-5933-4113-a0f6-6492f9307e8c@github.com>
 <0wXoRA8GQ4MH0Od2IIbtumEUPp7HntPi4JjCQ6wR6pA=.4a81b3b3-c66a-465c-9146-90e547999610@github.com>
Message-ID: <7Dq3-vDR5zb_GHRC2_6RgqZBiYcDcpVWIK43t0XoKaw=.3669664d-018e-4639-a5bd-4ac82b2f24e7@github.com>

On Fri, 25 Mar 2022 17:14:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Looks good - should we take the change and also rename libclang_home to llvm_home?

Good idea. Did that.

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

PR: https://git.openjdk.java.net/jextract/pull/8

From duke at openjdk.java.net  Fri Mar 25 19:46:05 2022
From: duke at openjdk.java.net (Ethan McCue)
Date: Fri, 25 Mar 2022 19:46:05 GMT
Subject: RFR: 7903132: Replace casts with type test pattern
In-Reply-To: <z_e-B24GHsjIxdfL3Y9mfSOkOSoND7dtn6BEXeu2KzA=.83528885-3a1e-4f89-80ff-6c1a8bf0426d@github.com>
References: <mdEDtqpZUigsk9HMSgsvbAC18VDpmi__EHfWxe_vNDU=.b7f55c58-a529-40bd-b02a-58f8cb78b1f0@github.com>
 <mTZDIfyojw2h-EGs0cJP714hYQ7_Z_LU_ky4bvauGpg=.b4f66469-733e-4416-8c09-0335786bb56e@github.com>
 <IBa0KU2JwX8WUclxkO238NSdWtd88Y0_zLGT7oId9a0=.e82a8a0f-37ae-4dc4-97da-6cec284966af@github.com>
 <CsC9ALCOc6JZchd_bK_cCwVoqUK1VqJeS84jgxch8tw=.5a28341d-df52-420d-9188-aacdcdce4e29@github.com>
 <z_e-B24GHsjIxdfL3Y9mfSOkOSoND7dtn6BEXeu2KzA=.83528885-3a1e-4f89-80ff-6c1a8bf0426d@github.com>
Message-ID: <fpmMC2yzKalWyD2AypnUs22_Z9JHLG5Lh4lWA43UBFI=.fa13d5f4-5269-4f2b-85e1-43673f848157@github.com>

On Fri, 25 Mar 2022 15:54:08 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> (I was counting on some CI/CD to be triggered on PR, which i suppose either isn't the case or isn't the case unless i get past the issue number check)
>
> Questions can be directed at the mailing list (either jextract-dev at openjdk.java.net or panama-dev at openjdk.java.net). You can send an email there without making an account as well (it will go through a moderation queue first).
> 
> I agree the error message is not great. In this case the issue seems to be this line in build.gradle:
> 
> 
> def clang_version = new File("${libclang_home}/lib/clang/").list()[0]
> 
> 
> i.e. the `libclang_home` directory does not have the expected directory structure. It is looking for a directory like `<libclang_home>/lib/clang/<VERSION>`. So please make sure that exists.

On a stock mac install with XCode it ended up being located at `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/` - in case that is of use to anyone.

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

PR: https://git.openjdk.java.net/jextract/pull/5

From duke at openjdk.java.net  Fri Mar 25 19:53:34 2022
From: duke at openjdk.java.net (Ethan McCue)
Date: Fri, 25 Mar 2022 19:53:34 GMT
Subject: RFR: 7903132: Replace casts with type test pattern [v2]
In-Reply-To: <mdEDtqpZUigsk9HMSgsvbAC18VDpmi__EHfWxe_vNDU=.b7f55c58-a529-40bd-b02a-58f8cb78b1f0@github.com>
References: <mdEDtqpZUigsk9HMSgsvbAC18VDpmi__EHfWxe_vNDU=.b7f55c58-a529-40bd-b02a-58f8cb78b1f0@github.com>
Message-ID: <MThbVuJGnK5WveK9aNMasxw_GS1OY8wBV-dKxr3M65w=.a1f7bf52-5d89-43ae-bf13-ae71d257d181@github.com>

> Replaces a handful of casts following type tests with the equivalent pattern syntax.
> 
> I cannot create a matching issue, as I do not have an account on the bug tracker.

Ethan McCue has updated the pull request incrementally with one additional commit since the last revision:

  Fix compile error with ClassSourceBuilder pattern

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/5/files
  - new: https://git.openjdk.java.net/jextract/pull/5/files/04247137..12c04e17

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=5&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=5&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jextract/pull/5.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/5/head:pull/5

PR: https://git.openjdk.java.net/jextract/pull/5

From duke at openjdk.java.net  Fri Mar 25 19:59:41 2022
From: duke at openjdk.java.net (Ethan McCue)
Date: Fri, 25 Mar 2022 19:59:41 GMT
Subject: RFR: 7903132: Replace casts with type test pattern [v3]
In-Reply-To: <mdEDtqpZUigsk9HMSgsvbAC18VDpmi__EHfWxe_vNDU=.b7f55c58-a529-40bd-b02a-58f8cb78b1f0@github.com>
References: <mdEDtqpZUigsk9HMSgsvbAC18VDpmi__EHfWxe_vNDU=.b7f55c58-a529-40bd-b02a-58f8cb78b1f0@github.com>
Message-ID: <3suli2gx3hgKgkN9qjrKM8qDMDwkZFEVGJAHavLLVRc=.e22eb45d-348f-40a1-a76f-d359bafca3ea@github.com>

> Replaces a handful of casts following type tests with the equivalent pattern syntax.
> 
> I cannot create a matching issue, as I do not have an account on the bug tracker.

Ethan McCue has updated the pull request incrementally with one additional commit since the last revision:

  Use patterns inline with && expression when possible for equals

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/5/files
  - new: https://git.openjdk.java.net/jextract/pull/5/files/12c04e17..63e2aa7a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=5&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=5&range=01-02

  Stats: 22 lines in 4 files changed: 1 ins; 9 del; 12 mod
  Patch: https://git.openjdk.java.net/jextract/pull/5.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/5/head:pull/5

PR: https://git.openjdk.java.net/jextract/pull/5

From duke at openjdk.java.net  Fri Mar 25 19:59:41 2022
From: duke at openjdk.java.net (Ethan McCue)
Date: Fri, 25 Mar 2022 19:59:41 GMT
Subject: RFR: 7903132: Replace casts with type test pattern [v3]
In-Reply-To: <qLgQ2AAT7wC51AsGKUPmurF3eYd8DF53oXn5j8gHRio=.594fb1af-4111-409e-aaa9-bedca42c1e22@github.com>
References: <mdEDtqpZUigsk9HMSgsvbAC18VDpmi__EHfWxe_vNDU=.b7f55c58-a529-40bd-b02a-58f8cb78b1f0@github.com>
 <mTZDIfyojw2h-EGs0cJP714hYQ7_Z_LU_ky4bvauGpg=.b4f66469-733e-4416-8c09-0335786bb56e@github.com>
 <IBa0KU2JwX8WUclxkO238NSdWtd88Y0_zLGT7oId9a0=.e82a8a0f-37ae-4dc4-97da-6cec284966af@github.com>
 <qLgQ2AAT7wC51AsGKUPmurF3eYd8DF53oXn5j8gHRio=.594fb1af-4111-409e-aaa9-bedca42c1e22@github.com>
Message-ID: <TiNvZobt_VD8McGn-pDCXS5AOmK7qP8wft7n0hUfpIk=.4742a724-8e1f-4103-bed0-4bfce014b409@github.com>

On Fri, 25 Mar 2022 16:08:20 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Strictly speaking, the whole method body could be merged into one expression. Its the realm of infinite bikesheds though, and I did not / do not know if there is a set of implicit style choices there.
>
> Well, we're on the topic of style changes already, so let's pull the string. This is new territory, so I think this is where we decide this :)
> 
> Merging the `instanceof` into the expression avoids having the pattern variable be carried over to outside of the `if` block, which I think is better.
> 
> The `this == other` check above that doesn't have the same problem.

I don't have any particularly strong opinions there, so I made that as the change, leaving the `this == other` checks alone

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

PR: https://git.openjdk.java.net/jextract/pull/5

From mcimadamore at openjdk.java.net  Fri Mar 25 21:49:49 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 25 Mar 2022 21:49:49 GMT
Subject: RFR: 7903132: Replace casts with type test pattern [v3]
In-Reply-To: <3suli2gx3hgKgkN9qjrKM8qDMDwkZFEVGJAHavLLVRc=.e22eb45d-348f-40a1-a76f-d359bafca3ea@github.com>
References: <mdEDtqpZUigsk9HMSgsvbAC18VDpmi__EHfWxe_vNDU=.b7f55c58-a529-40bd-b02a-58f8cb78b1f0@github.com>
 <3suli2gx3hgKgkN9qjrKM8qDMDwkZFEVGJAHavLLVRc=.e22eb45d-348f-40a1-a76f-d359bafca3ea@github.com>
Message-ID: <WfoEWm9y6FN_M24RMN57S2h4TsSAhgVwRJSXpSfNyYg=.9b143183-d34f-4a82-803d-00979b376f7c@github.com>

On Fri, 25 Mar 2022 19:59:41 GMT, Ethan McCue <duke at openjdk.java.net> wrote:

>> Replaces a handful of casts following type tests with the equivalent pattern syntax.
>> 
>> I cannot create a matching issue, as I do not have an account on the bug tracker.
>
> Ethan McCue has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use patterns inline with && expression when possible for equals

Looks good

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

Marked as reviewed by mcimadamore (Committer).

PR: https://git.openjdk.java.net/jextract/pull/5

From jvernee at openjdk.java.net  Fri Mar 25 23:21:04 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 25 Mar 2022 23:21:04 GMT
Subject: RFR: 7903132: Replace casts with type test pattern [v3]
In-Reply-To: <3suli2gx3hgKgkN9qjrKM8qDMDwkZFEVGJAHavLLVRc=.e22eb45d-348f-40a1-a76f-d359bafca3ea@github.com>
References: <mdEDtqpZUigsk9HMSgsvbAC18VDpmi__EHfWxe_vNDU=.b7f55c58-a529-40bd-b02a-58f8cb78b1f0@github.com>
 <3suli2gx3hgKgkN9qjrKM8qDMDwkZFEVGJAHavLLVRc=.e22eb45d-348f-40a1-a76f-d359bafca3ea@github.com>
Message-ID: <wTwZouWahuCgWT3sgRnWoWihRb7SMGCmjwHsB1glrGY=.2feb68ef-1448-44bb-b533-324bb63a17cb@github.com>

On Fri, 25 Mar 2022 19:59:41 GMT, Ethan McCue <duke at openjdk.java.net> wrote:

>> Replaces a handful of casts following type tests with the equivalent pattern syntax.
>> 
>> I cannot create a matching issue, as I do not have an account on the bug tracker.
>
> Ethan McCue has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use patterns inline with && expression when possible for equals

Marked as reviewed by jvernee (no project role).

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

PR: https://git.openjdk.java.net/jextract/pull/5

From jvernee at openjdk.java.net  Mon Mar 28 10:42:55 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 28 Mar 2022 10:42:55 GMT
Subject: RFR: Testing GHA [v2]
In-Reply-To: <nxSlAcuYrE2_UO11fQbmJvA64X5KXABjmCRii5Gjb_U=.06f8ee2d-2628-4a90-830b-ca81e0986554@github.com>
References: <OX_sp1R62QIyLmrLanHNZv4IRhIregZW8ChTvukgtRY=.245dfd5b-0eb8-4c02-bc65-8a92d8c37ebf@github.com>
 <X-DE8XjmJ-rXy6-ZcENEY3RhW1rNiEWLQTiFbmXdkAw=.b5f7a735-9efc-44a2-8920-234b77fa007f@github.com>
 <WHgVpB1Y6rHOs5rVBVgFhKlLzfeouPjHvHUTUo_VnAg=.122b689a-2b34-4931-a2ce-eb2b500c32eb@github.com>
 <TE-zXrc_OtY6ITcTCRBI4gdNyxGds2mThAOIdVVt0SY=.9480d1d0-5305-482d-b55d-f15934658339@github.com>
 <nxSlAcuYrE2_UO11fQbmJvA64X5KXABjmCRii5Gjb_U=.06f8ee2d-2628-4a90-830b-ca81e0986554@github.com>
Message-ID: <2rHgwPAo6zS_DvyAiEK2bSsFeM7da3Dwdz3KBL_9Hx0=.81ef350e-cb60-4377-b95e-2bf84668fd48@github.com>

On Fri, 25 Mar 2022 17:03:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hmm, okay. I'll use that binary instead. There was no package for 20.04 for LLVM 13.0.1
>
> will not this break when `ubuntu-latest` binds to 22.04? Can we specify a specific ubuntu version?

Ah, right. I'll set the version explicitly.

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

PR: https://git.openjdk.java.net/jextract/pull/6

From jvernee at openjdk.java.net  Mon Mar 28 10:54:34 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 28 Mar 2022 10:54:34 GMT
Subject: RFR: Testing GHA [v4]
In-Reply-To: <OX_sp1R62QIyLmrLanHNZv4IRhIregZW8ChTvukgtRY=.245dfd5b-0eb8-4c02-bc65-8a92d8c37ebf@github.com>
References: <OX_sp1R62QIyLmrLanHNZv4IRhIregZW8ChTvukgtRY=.245dfd5b-0eb8-4c02-bc65-8a92d8c37ebf@github.com>
Message-ID: <tzGFE8VmC6cXqMR3xMmOV37nZGvhMedy0EFyWwUj1to=.0fc9f219-7c32-40d3-a9ff-d3950cda5ed1@github.com>

> Add a basic actions workflow that runs the tests on pull requests

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Set sepcific ubuntu version

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/6/files
  - new: https://git.openjdk.java.net/jextract/pull/6/files/998e2adc..e82f6f7f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=6&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=6&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jextract/pull/6.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/6/head:pull/6

PR: https://git.openjdk.java.net/jextract/pull/6

From jvernee at openjdk.java.net  Mon Mar 28 11:09:57 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 28 Mar 2022 11:09:57 GMT
Subject: Integrated: 7903134: Improve error reporting in jextract gradle build
In-Reply-To: <UGNQ6THETKMxmQZ1_qXET__r1VD9FqicdqJCQJ0of0Q=.17cb2bb7-5933-4113-a0f6-6492f9307e8c@github.com>
References: <UGNQ6THETKMxmQZ1_qXET__r1VD9FqicdqJCQJ0of0Q=.17cb2bb7-5933-4113-a0f6-6492f9307e8c@github.com>
Message-ID: <-uJzMmn2myA6k7zr2kK5cCpsmwtVhDIk-BpoJD7w0Us=.698b4f18-6fc4-4491-93c5-1fa1690fb6f1@github.com>

On Fri, 25 Mar 2022 16:16:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Improve error reporting around missing LLVM paths in jextract gradle build.
> 
> This patch tries to detect missing paths and throw a descriptive error, instead of a more cryptic one.
> 
> I've also added the `.idea` folder to the `.gitignore` file.

This pull request has now been integrated.

Changeset: 6018d1ec
Author:    Jorn Vernee <jvernee at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jextract/commit/6018d1ec3dbe3c2326f6720db9731396064bf293
Stats:     24 lines in 3 files changed: 18 ins; 0 del; 6 mod

7903134: Improve error reporting in jextract gradle build

Reviewed-by: mcimadamore

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

PR: https://git.openjdk.java.net/jextract/pull/8

From sundar at openjdk.java.net  Mon Mar 28 11:40:02 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Mon, 28 Mar 2022 11:40:02 GMT
Subject: Integrated: 7903133: add lp_solve sample
In-Reply-To: <UMRtLDyDTBKsr9g4-T41KDqTjkAILkIz9qektMu6GS0=.36d15052-8594-4757-b77e-d97f8ba5c822@github.com>
References: <UMRtLDyDTBKsr9g4-T41KDqTjkAILkIz9qektMu6GS0=.36d15052-8594-4757-b77e-d97f8ba5c822@github.com>
Message-ID: <SlhJCqc4HAA2jlEG8_D3ksg23rCliea6vZtUFVIHQrw=.074c0a20-7f8f-4086-8d02-97f69732417b@github.com>

On Fri, 25 Mar 2022 15:48:41 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> Adding lp_solve jextract sample. This is more or less straight port of a C example.

This pull request has now been integrated.

Changeset: fba72206
Author:    Athijegannathan Sundararajan <sundar at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jextract/commit/fba72206d5c1263b38f2f74fab56afc57b4dc936
Stats:     166 lines in 7 files changed: 166 ins; 0 del; 0 mod

7903133: add lp_solve sample

Reviewed-by: mcimadamore

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

PR: https://git.openjdk.java.net/jextract/pull/7

From duke at openjdk.java.net  Mon Mar 28 11:40:09 2022
From: duke at openjdk.java.net (Ethan McCue)
Date: Mon, 28 Mar 2022 11:40:09 GMT
Subject: Integrated: 7903132: Replace casts with type test pattern
In-Reply-To: <mdEDtqpZUigsk9HMSgsvbAC18VDpmi__EHfWxe_vNDU=.b7f55c58-a529-40bd-b02a-58f8cb78b1f0@github.com>
References: <mdEDtqpZUigsk9HMSgsvbAC18VDpmi__EHfWxe_vNDU=.b7f55c58-a529-40bd-b02a-58f8cb78b1f0@github.com>
Message-ID: <bjn-bzYWL1TSbdEAC4JQ3pgUmJxs3fTsuNyk6mndmdg=.0f276555-a2c0-423d-b007-3f7535a19a06@github.com>

On Thu, 24 Mar 2022 22:48:41 GMT, Ethan McCue <duke at openjdk.java.net> wrote:

> Replaces a handful of casts following type tests with the equivalent pattern syntax.
> 
> I cannot create a matching issue, as I do not have an account on the bug tracker.

This pull request has now been integrated.

Changeset: 4c0e547c
Author:    Ethan McCue <ethan at mccue.dev>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jextract/commit/4c0e547cf4a403a758308254f714d18b0af6fea6
Stats:     94 lines in 13 files changed: 2 ins; 29 del; 63 mod

7903132: Replace casts with type test pattern

Reviewed-by: mcimadamore, jvernee

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

PR: https://git.openjdk.java.net/jextract/pull/5

From mcimadamore at openjdk.java.net  Mon Mar 28 11:40:52 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 28 Mar 2022 11:40:52 GMT
Subject: RFR: Testing GHA [v4]
In-Reply-To: <tzGFE8VmC6cXqMR3xMmOV37nZGvhMedy0EFyWwUj1to=.0fc9f219-7c32-40d3-a9ff-d3950cda5ed1@github.com>
References: <OX_sp1R62QIyLmrLanHNZv4IRhIregZW8ChTvukgtRY=.245dfd5b-0eb8-4c02-bc65-8a92d8c37ebf@github.com>
 <tzGFE8VmC6cXqMR3xMmOV37nZGvhMedy0EFyWwUj1to=.0fc9f219-7c32-40d3-a9ff-d3950cda5ed1@github.com>
Message-ID: <IO7r9JvCWirBViwdW_AmAbaaEJQcfpq0MFXW-PJzeQs=.13f937f5-aa0a-41db-97f3-885bdbf3b99f@github.com>

On Mon, 28 Mar 2022 10:54:34 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Add a basic actions workflow that runs the tests on pull requests
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set sepcific ubuntu version

Looks good

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

Marked as reviewed by mcimadamore (Committer).

PR: https://git.openjdk.java.net/jextract/pull/6

From jvernee at openjdk.java.net  Mon Mar 28 11:40:52 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 28 Mar 2022 11:40:52 GMT
Subject: RFR: Testing GHA [v4]
In-Reply-To: <tzGFE8VmC6cXqMR3xMmOV37nZGvhMedy0EFyWwUj1to=.0fc9f219-7c32-40d3-a9ff-d3950cda5ed1@github.com>
References: <OX_sp1R62QIyLmrLanHNZv4IRhIregZW8ChTvukgtRY=.245dfd5b-0eb8-4c02-bc65-8a92d8c37ebf@github.com>
 <tzGFE8VmC6cXqMR3xMmOV37nZGvhMedy0EFyWwUj1to=.0fc9f219-7c32-40d3-a9ff-d3950cda5ed1@github.com>
Message-ID: <Vs1fkBFdcoCOdeEHueIn-yzZ9hAfO-ycPWXFn50Bd0w=.45450b6a-a1ed-4052-a514-0c3e42d7b31d@github.com>

On Mon, 28 Mar 2022 10:54:34 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Add a basic actions workflow that runs the tests on pull requests
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set sepcific ubuntu version

I'll wait for actions to be turned on for this repo. That should allow us to give this another test run before integrating.

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

PR: https://git.openjdk.java.net/jextract/pull/6

From jvernee at openjdk.java.net  Mon Mar 28 15:06:11 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 28 Mar 2022 15:06:11 GMT
Subject: Withdrawn: Testing GHA
In-Reply-To: <OX_sp1R62QIyLmrLanHNZv4IRhIregZW8ChTvukgtRY=.245dfd5b-0eb8-4c02-bc65-8a92d8c37ebf@github.com>
References: <OX_sp1R62QIyLmrLanHNZv4IRhIregZW8ChTvukgtRY=.245dfd5b-0eb8-4c02-bc65-8a92d8c37ebf@github.com>
Message-ID: <IxRy7jUCD-C0qd_P80x6Df4_r-zIEc6bIXaHxNs7fsE=.e7166370-ab02-4e6e-a33b-7d9f1252df57@github.com>

On Thu, 24 Mar 2022 23:53:18 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Add a basic actions workflow that runs the tests on pull requests

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jextract/pull/6

From duke at openjdk.java.net  Mon Mar 28 16:37:22 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Mon, 28 Mar 2022 16:37:22 GMT
Subject: RFR: Update Readme with macOs specifics
Message-ID: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>

The macOs libclang location as well as build output differ enough to warrant specific information. In particular the use of the XCode based path to find the libclang is not an easy find. The output also makes use of jpackage with `app-image` type, but the macOs _.app_ layout different enough on macOs.

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

Commit messages:
 - Update Readme with macOs specifics

Changes: https://git.openjdk.java.net/jextract/pull/10/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jextract&pr=10&range=00
  Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jextract/pull/10.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/10/head:pull/10

PR: https://git.openjdk.java.net/jextract/pull/10

From duke at openjdk.java.net  Mon Mar 28 16:42:57 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Mon, 28 Mar 2022 16:42:57 GMT
Subject: RFR: Update Readme with macOs specifics
In-Reply-To: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
Message-ID: <5s6Na2_YWQXCLyWRky3EhFDBOQgJrdDL_hKheT9XDn4=.2004e79f-ff8b-4b6a-ad1f-8b39ef9206d7@github.com>

On Mon, 28 Mar 2022 16:32:42 GMT, Brice Dutheil <duke at openjdk.java.net> wrote:

> The macOs libclang location as well as build output differ enough to warrant specific information. In particular the use of the XCode based path to find the libclang is not an easy find. The output also makes use of jpackage with `app-image` type, but the macOs _.app_ layout different enough on macOs.

README.md line 12:

> 10: 
> 11: ```sh
> 12: $ sh ./gradlew -Pjdk18_home=<jdk18_home_dir> -Pllvm_home=<libclang_dir> clean verify

I refered to `libclang_dir`, however I wonder if the value in the angle brackets has to be renamed as `llvm_home` as well.

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

PR: https://git.openjdk.java.net/jextract/pull/10

From mcimadamore at openjdk.java.net  Mon Mar 28 17:04:12 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 28 Mar 2022 17:04:12 GMT
Subject: RFR: Update Readme with macOs specifics
In-Reply-To: <5s6Na2_YWQXCLyWRky3EhFDBOQgJrdDL_hKheT9XDn4=.2004e79f-ff8b-4b6a-ad1f-8b39ef9206d7@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <5s6Na2_YWQXCLyWRky3EhFDBOQgJrdDL_hKheT9XDn4=.2004e79f-ff8b-4b6a-ad1f-8b39ef9206d7@github.com>
Message-ID: <CR8J1K31kor9HyABFC-DEpFBhE5bFTAM5WPz-xT3ikA=.e1dba9bf-ef4b-42fd-8f0f-b244a2d65854@github.com>

On Mon, 28 Mar 2022 16:39:28 GMT, Brice Dutheil <duke at openjdk.java.net> wrote:

>> The macOs libclang location as well as build output differ enough to warrant specific information. In particular the use of the XCode based path to find the libclang is not an easy find. The output also makes use of jpackage with `app-image` type, but the macOs _.app_ layout different enough on macOs.
>
> README.md line 12:
> 
>> 10: 
>> 11: ```sh
>> 12: $ sh ./gradlew -Pjdk18_home=<jdk18_home_dir> -Pllvm_home=<libclang_dir> clean verify
> 
> I refered to `libclang_dir`, however I wonder if the value in the angle brackets has to be renamed as `llvm_home` as well.

This has been updated in a recent PR - please try to refresh your branch

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

PR: https://git.openjdk.java.net/jextract/pull/10

From jvernee at openjdk.java.net  Mon Mar 28 17:04:13 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 28 Mar 2022 17:04:13 GMT
Subject: RFR: Update Readme with macOs specifics
In-Reply-To: <CR8J1K31kor9HyABFC-DEpFBhE5bFTAM5WPz-xT3ikA=.e1dba9bf-ef4b-42fd-8f0f-b244a2d65854@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <5s6Na2_YWQXCLyWRky3EhFDBOQgJrdDL_hKheT9XDn4=.2004e79f-ff8b-4b6a-ad1f-8b39ef9206d7@github.com>
 <CR8J1K31kor9HyABFC-DEpFBhE5bFTAM5WPz-xT3ikA=.e1dba9bf-ef4b-42fd-8f0f-b244a2d65854@github.com>
Message-ID: <4Y29zZHEnu57ZEuUJAaHXeh4YLra8tn-XyXfar-sgjU=.99a9bbf4-6abc-48a6-822b-f8fad8601907@github.com>

On Mon, 28 Mar 2022 17:00:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> README.md line 12:
>> 
>>> 10: 
>>> 11: ```sh
>>> 12: $ sh ./gradlew -Pjdk18_home=<jdk18_home_dir> -Pllvm_home=<libclang_dir> clean verify
>> 
>> I refered to `libclang_dir`, however I wonder if the value in the angle brackets has to be renamed as `llvm_home` as well.
>
> This has been updated in a recent PR - please try to refresh your branch

Yes, that was missed previously. I've addressed in my PR here: https://github.com/openjdk/jextract/pull/9

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

PR: https://git.openjdk.java.net/jextract/pull/10

From jvernee at openjdk.java.net  Mon Mar 28 17:05:29 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 28 Mar 2022 17:05:29 GMT
Subject: RFR: 7903136: Don't require jdk18_home to be set in jextract gradle
 build
Message-ID: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>

Drop the requirement to set `jdk18_home` in the gradle build, and rely instead on `JAVA_HOME` being set to JDK 18.

I've also updated the build instructions. The `-Pjtreg_home` flag seems to have been dropped by accident from the test command. I've re-added it. Also renamed `libclang_dir` -> `llvm_dir` which was missed in an earlier change.

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

Commit messages:
 - libclang_dir -> llvm_dir in instructions
 - Use java.home instead of JAVA_HOME
 - reorder build instructions
 - Add missing jtreg_home property to test command
 - Use JDK 18 from Java home, and add a JDK version check

Changes: https://git.openjdk.java.net/jextract/pull/9/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jextract&pr=9&range=00
  Issue: https://bugs.openjdk.java.net/browse/CODETOOLS-7903136
  Stats: 43 lines in 2 files changed: 35 ins; 3 del; 5 mod
  Patch: https://git.openjdk.java.net/jextract/pull/9.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/9/head:pull/9

PR: https://git.openjdk.java.net/jextract/pull/9

From mcimadamore at openjdk.java.net  Mon Mar 28 17:08:55 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 28 Mar 2022 17:08:55 GMT
Subject: RFR: Update Readme with macOs specifics
In-Reply-To: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
Message-ID: <awocHTt67BkYmnzLCuhAzcJnZe4Cp-jUJn7LIuEKk4E=.f33647b9-da10-4a79-aa55-063cb3f61c77@github.com>

On Mon, 28 Mar 2022 16:32:42 GMT, Brice Dutheil <duke at openjdk.java.net> wrote:

> The macOs libclang location as well as build output differ enough to warrant specific information. In particular the use of the XCode based path to find the libclang is not an easy find. The output also makes use of jpackage with `app-image` type, but the macOs _.app_ layout different enough on macOs.

In general the changes look ok - but I wonder if this leaves things inconsistent. E.g. in the current document there's no specific description for any of the platforms involved. With your changes we go quite in a bit of details to explain how to fetch libclang for macOs users - but we leave e.g. Linux users in the dark. In general, the process of downloading an LLVM snapshot from the LLVM binary website works, I think, on every platform/OS (including macOs). The instruction you provide seem more to answer the question: what if I _already_ have some LLVM installed (which can be true with macOs with Xcode or brew, but also on Linux e.g. with apt).

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

PR: https://git.openjdk.java.net/jextract/pull/10

From jvernee at openjdk.java.net  Mon Mar 28 17:26:07 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 28 Mar 2022 17:26:07 GMT
Subject: RFR: Update Readme with macOs specifics
In-Reply-To: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
Message-ID: <ctQVwTOzcvnPd9ULtWlAWQRtNlkAlbeoFMdnWgJT668=.dedbadde-1e88-4e2f-b2a2-9ce94a4e3d43@github.com>

On Mon, 28 Mar 2022 16:32:42 GMT, Brice Dutheil <duke at openjdk.java.net> wrote:

> The macOs libclang location as well as build output differ enough to warrant specific information. In particular the use of the XCode based path to find the libclang is not an easy find. The output also makes use of jpackage with `app-image` type, but the macOs _.app_ layout different enough on macOs.

README.md line 19:

> 17: * `/Library/Developer/CommandLineTools/usr/` if using Command Line Tools
> 18: * `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/` if using XCode
> 19: * `$(brew --prefix llvm)` if using the [LLVM install from Homebrew](https://formulae.brew.sh/formula/llvm#default)

FWIW, different package managers probably have different packages and folder structures.

I think the recommended way to get LLVM is still through the release page here: https://github.com/llvm/llvm-project/releases/tag/llvmorg-14.0.0 after which the tar can be extracted to any location, and `-Pllvm_home` pointed to that.

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

PR: https://git.openjdk.java.net/jextract/pull/10

From jvernee at openjdk.java.net  Mon Mar 28 17:35:54 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 28 Mar 2022 17:35:54 GMT
Subject: RFR: Update Readme with macOs specifics
In-Reply-To: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
Message-ID: <SQ6rlaidCY29WgfR3hud8bV0YurqsTHmrukvrDznkP0=.12387b20-30a8-4e4e-908a-88c2ebe79bd8@github.com>

On Mon, 28 Mar 2022 16:32:42 GMT, Brice Dutheil <duke at openjdk.java.net> wrote:

> The macOs libclang location as well as build output differ enough to warrant specific information. In particular the use of the XCode based path to find the libclang is not an easy find. The output also makes use of jpackage with `app-image` type, but the macOs _.app_ layout different enough on macOs.

I'm also feeling a little split here. Providing many different instructions for different setups seems more likely to leave the documentation for some of them going out of date (this has been my experience with other projects). I think I'd prefer having 1 recommended way of installing LLVM, which is the LLVM release page, which we can also guarantee works.

For now though, I don't mind listing the alternatives. But I'd suggest hiding them in a spoiler block (using `<details><summary>LLVM location for alternative packages</summary>...</details>`). And I think we should spell out the recommended way to get the package (download, unzip/untar, point `libclang_dir` to extracted folder) a bit more front and center as well.

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

PR: https://git.openjdk.java.net/jextract/pull/10

From mcimadamore at openjdk.java.net  Mon Mar 28 17:44:04 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 28 Mar 2022 17:44:04 GMT
Subject: RFR: 7903136: Don't require jdk18_home to be set in jextract
 gradle build
In-Reply-To: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
References: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
Message-ID: <X2RgItiNM4K8R0rGgvEGt2AL3mlORFGCLABXgRoU8FM=.97decba8-7ecb-4406-8fe0-7495ee726547@github.com>

On Mon, 28 Mar 2022 16:02:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Drop the requirement to set `jdk18_home` in the gradle build, and rely instead on `JAVA_HOME` being set to JDK 18.
> 
> I've also updated the build instructions. The `-Pjtreg_home` flag seems to have been dropped by accident from the test command. I've re-added it. Also renamed `libclang_dir` -> `llvm_dir` which was missed in an earlier change.

Not fully convinced about this. Java 18 works, yes. But what about 19 EA, or Panama EA (for foreign-preview changes) ? My feeling is that this project will always live a bit in the bleeding edge, so a more manual way to specify which JDK should be used should be possible, at the very least as an escape hatch.

Then, on a more subjective matter, I find setting JAVA_HOME and then calling the executable to be in the same league as specifying a custom property. But maybe there are some advantages - e.g.. maybe in terms of friendliness w.r.t. IDE support?

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

PR: https://git.openjdk.java.net/jextract/pull/9

From jvernee at openjdk.java.net  Mon Mar 28 17:55:05 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 28 Mar 2022 17:55:05 GMT
Subject: RFR: 7903136: Don't require jdk18_home to be set in jextract
 gradle build
In-Reply-To: <X2RgItiNM4K8R0rGgvEGt2AL3mlORFGCLABXgRoU8FM=.97decba8-7ecb-4406-8fe0-7495ee726547@github.com>
References: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
 <X2RgItiNM4K8R0rGgvEGt2AL3mlORFGCLABXgRoU8FM=.97decba8-7ecb-4406-8fe0-7495ee726547@github.com>
Message-ID: <GAYgxv-_iHQs1tmAa8sWNyhRb1o48-U_gY601UIcwhQ=.7d1f4e1e-ef5d-4f8e-95cc-548fbae374bd@github.com>

On Mon, 28 Mar 2022 17:40:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> But maybe there are some advantages - e.g.. maybe in terms of friendliness w.r.t. IDE support?

That too. I looked at it a bit yesterday, and it doesn't seem like IntelliJ supports specifying flags to it's Gradle build.

JAVA_HOME can also be set on shell startup, which would avoid having to set anything at all. Or, at least it would only have to be set once per shell session.

These are quality of life improvements I think.

Being able to manually specify the JDK is reasonable though. I can keep a `-Pjdk` flag, and adjust the version check to check for 18+ instead of exactly 18 (not sure how easy that is for EA versions though, maybe the check should just be dropped).

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

PR: https://git.openjdk.java.net/jextract/pull/9

From mcimadamore at openjdk.java.net  Mon Mar 28 18:18:02 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 28 Mar 2022 18:18:02 GMT
Subject: RFR: 7903136: Don't require jdk18_home to be set in jextract
 gradle build
In-Reply-To: <GAYgxv-_iHQs1tmAa8sWNyhRb1o48-U_gY601UIcwhQ=.7d1f4e1e-ef5d-4f8e-95cc-548fbae374bd@github.com>
References: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
 <X2RgItiNM4K8R0rGgvEGt2AL3mlORFGCLABXgRoU8FM=.97decba8-7ecb-4406-8fe0-7495ee726547@github.com>
 <GAYgxv-_iHQs1tmAa8sWNyhRb1o48-U_gY601UIcwhQ=.7d1f4e1e-ef5d-4f8e-95cc-548fbae374bd@github.com>
Message-ID: <2KquTuOa_mhfIhWA9yEf6ju9gUzUSni86Uf0O2D5Ot0=.71988694-dd0a-4b84-9e54-2260217eb6f3@github.com>

On Mon, 28 Mar 2022 17:51:48 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> These are quality of life improvements I think.

I don't object to wanting to improve the quality of the build process experience. At the same time I'm worried about doing something (like this PR does) which might work well in some cases, and not at all in others, at which point you need to have _two_ ways to do the same thing, which leads to a more complex build.

My feeling is that a more principled approach, if we really aim for quality of life, would be to keep the parameters, but add a section where we infer which artifacts (JDK, libclang) we need depending on the arch/OS, and then fetch them automatically (but users can override if they so wish).

That said, I have no super strong opinions on this. I suppose we could also try this out and see how it works out in practice, and correct if/when needed.

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

PR: https://git.openjdk.java.net/jextract/pull/9

From duke at openjdk.java.net  Mon Mar 28 19:25:05 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Mon, 28 Mar 2022 19:25:05 GMT
Subject: RFR: Update Readme with macOs specifics
In-Reply-To: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
Message-ID: <rwQ-2LkCxq6FH0lfX7wxaqg7Y79UAdSh6zLP_ArDeDU=.6e4bad2b-f878-40ef-a321-c9a8d0d54c8b@github.com>

On Mon, 28 Mar 2022 16:32:42 GMT, Brice Dutheil <duke at openjdk.java.net> wrote:

> The macOs libclang location as well as build output differ enough to warrant specific information. In particular the use of the XCode based path to find the libclang is not an easy find. The output also makes use of jpackage with `app-image` type, but the macOs _.app_ layout different enough on macOs.

I felt the same and wondered if a different file was needed, but the details block looks good for me.

Regarding Linux (or else) I felt this was an opportunity to document these LLVM installs as well. And may improve usability.

After reading your comment I think that if the build should prefer an actual download of LLVM it might be better to write a gradle task that performs the download and extraction. It should be quite ready and it might improve the deterministic aspect as the build.

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

PR: https://git.openjdk.java.net/jextract/pull/10

From duke at openjdk.java.net  Mon Mar 28 19:29:08 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Mon, 28 Mar 2022 19:29:08 GMT
Subject: RFR: Update Readme with macOs specifics
In-Reply-To: <ctQVwTOzcvnPd9ULtWlAWQRtNlkAlbeoFMdnWgJT668=.dedbadde-1e88-4e2f-b2a2-9ce94a4e3d43@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <ctQVwTOzcvnPd9ULtWlAWQRtNlkAlbeoFMdnWgJT668=.dedbadde-1e88-4e2f-b2a2-9ce94a4e3d43@github.com>
Message-ID: <gJ49RviYb_HHj_7lknvUjPE0R7C2fqsYHEsng9cb93I=.06408b04-405b-42b9-b28e-46373a9a4106@github.com>

On Mon, 28 Mar 2022 17:04:14 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> The macOs libclang location as well as build output differ enough to warrant specific information. In particular the use of the XCode based path to find the libclang is not an easy find. The output also makes use of jpackage with `app-image` type, but the macOs _.app_ layout different enough on macOs.
>
> README.md line 19:
> 
>> 17: * `/Library/Developer/CommandLineTools/usr/` if using Command Line Tools
>> 18: * `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/` if using XCode
>> 19: * `$(brew --prefix llvm)` if using the [LLVM install from Homebrew](https://formulae.brew.sh/formula/llvm#default)
> 
> FWIW, different package managers probably have different packages and folder structures.
> 
> I think the recommended way to get LLVM is still through the release page here: https://github.com/llvm/llvm-project/releases/tag/llvmorg-14.0.0 after which the tar can be extracted to any location, and `-Pllvm_home` pointed to that.

I have tested these combinations, although there's some differences in the actual library objects present in the above installs.

Although I must say I didn't tried jtreg.

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

PR: https://git.openjdk.java.net/jextract/pull/10

From mcimadamore at openjdk.java.net  Mon Mar 28 20:29:05 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 28 Mar 2022 20:29:05 GMT
Subject: RFR: Update Readme with macOs specifics
In-Reply-To: <rwQ-2LkCxq6FH0lfX7wxaqg7Y79UAdSh6zLP_ArDeDU=.6e4bad2b-f878-40ef-a321-c9a8d0d54c8b@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <rwQ-2LkCxq6FH0lfX7wxaqg7Y79UAdSh6zLP_ArDeDU=.6e4bad2b-f878-40ef-a321-c9a8d0d54c8b@github.com>
Message-ID: <QtRTj8MzhFcPCLgMAAVzFVsii0dDvLEaVdJTSpNUSDk=.6b8bf840-836b-4d0e-a6d9-02ec284aa0e0@github.com>

On Mon, 28 Mar 2022 19:21:36 GMT, Brice Dutheil <duke at openjdk.java.net> wrote:

> After reading your comment I think that if the build should prefer an actual download of LLVM it might be better to write a gradle task that performs the download and extraction. It should be quite ready and it might improve the deterministic aspect as the build.

This is something we are considering, for both the JDK and libclang.

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

PR: https://git.openjdk.java.net/jextract/pull/10

From sundar at openjdk.java.net  Tue Mar 29 02:34:53 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Tue, 29 Mar 2022 02:34:53 GMT
Subject: RFR: 7903136: Don't require jdk18_home to be set in jextract
 gradle build
In-Reply-To: <GAYgxv-_iHQs1tmAa8sWNyhRb1o48-U_gY601UIcwhQ=.7d1f4e1e-ef5d-4f8e-95cc-548fbae374bd@github.com>
References: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
 <X2RgItiNM4K8R0rGgvEGt2AL3mlORFGCLABXgRoU8FM=.97decba8-7ecb-4406-8fe0-7495ee726547@github.com>
 <GAYgxv-_iHQs1tmAa8sWNyhRb1o48-U_gY601UIcwhQ=.7d1f4e1e-ef5d-4f8e-95cc-548fbae374bd@github.com>
Message-ID: <N_HdYYBPYqF7_2vuSMqROz1tAuI4x80HSvTNTSnpDwE=.e28bfdb2-de83-4b6a-9d16-0214242e646b@github.com>

On Mon, 28 Mar 2022 17:51:48 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Being able to manually specify the JDK is reasonable though. I can keep a -Pjdk flag, and adjust the version check to >  check for 18+ instead of exactly 18 (not sure how easy that is for EA versions though, maybe the check should just be > dropped).

But the assumption is that jextract "18" will build and work with jdk18+ - which will not true after foreign-preview branch hits mainline. I think it is better to call "jdk18", "jdk19" explicitly till the point foreign-abi API becomes part of specification in some future jdk. At that point, we can have jdk<N>+ check.

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

PR: https://git.openjdk.java.net/jextract/pull/9

From duke at openjdk.java.net  Tue Mar 29 09:12:09 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Tue, 29 Mar 2022 09:12:09 GMT
Subject: RFR: 7903136: Don't require jdk18_home to be set in jextract
 gradle build
In-Reply-To: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
References: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
Message-ID: <5hXtIxNZpYGkWzYPfaUvZoJx6Xr8ZbAg9haAr5JpIug=.ecc59a15-85d2-4875-8fd5-a8706e9cd087@github.com>

On Mon, 28 Mar 2022 16:02:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Drop the requirement to set `jdk18_home` in the gradle build, and rely instead on `JAVA_HOME` being set to JDK 18.
> 
> I've also updated the build instructions. The `-Pjtreg_home` flag seems to have been dropped by accident from the test command. I've re-added it. Also renamed `libclang_dir` -> `llvm_dir` which was missed in an earlier change.

As an alternative to property or JAVA_HOME, did you consider using [Gradle java toolchains](https://docs.gradle.org/current/userguide/toolchains.html) ?

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

PR: https://git.openjdk.java.net/jextract/pull/9

From mcimadamore at openjdk.java.net  Tue Mar 29 09:20:58 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 29 Mar 2022 09:20:58 GMT
Subject: RFR: 7903136: Don't require jdk18_home to be set in jextract
 gradle build
In-Reply-To: <5hXtIxNZpYGkWzYPfaUvZoJx6Xr8ZbAg9haAr5JpIug=.ecc59a15-85d2-4875-8fd5-a8706e9cd087@github.com>
References: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
 <5hXtIxNZpYGkWzYPfaUvZoJx6Xr8ZbAg9haAr5JpIug=.ecc59a15-85d2-4875-8fd5-a8706e9cd087@github.com>
Message-ID: <0eo3REEcypv9VadZfut9z80pQ1R57Km4d62fXeSArZg=.c935bc3b-6531-4a6f-bb34-33529f21b7f3@github.com>

On Tue, 29 Mar 2022 09:08:54 GMT, Brice Dutheil <duke at openjdk.java.net> wrote:

> As an alternative to property or JAVA_HOME, did you consider using [Gradle java toolchains](https://docs.gradle.org/current/userguide/toolchains.html) ?

This was proposed here:
https://mail.openjdk.java.net/pipermail/panama-dev/2022-March/016665.html

While for regular projects toolchains is great - I'm not sure it seems to limiting here. If I specify `JavaLanguageVersion.of(19)` I get an error:

> Unable to download toolchain matching these requirements: {languageVersion=19, vendor=any, implementation=vendor-specific}

Which is understandable, given 19 doesn't really exists yet. I think what we'd like would be some kind of toolchain-like solution, but which is backed by https://jdk.java.net/

Otherwise, we're back to finding workarounds to override what toolchains does, and manually set a JDK (at least in some cases).

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

PR: https://git.openjdk.java.net/jextract/pull/9

From duke at openjdk.java.net  Tue Mar 29 09:41:06 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Tue, 29 Mar 2022 09:41:06 GMT
Subject: RFR: 7903136: Don't require jdk18_home to be set in jextract
 gradle build
In-Reply-To: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
References: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
Message-ID: <g8fDmMjpNx9wVfFPbq3L2W8JYDxhfX2kSEgkTuhQtIw=.785291f6-4e00-4cc6-9d8f-a6abd332e6a0@github.com>

On Mon, 28 Mar 2022 16:02:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Drop the requirement to set `jdk18_home` in the gradle build, and rely instead on `JAVA_HOME` being set to JDK 18.
> 
> I've also updated the build instructions. The `-Pjtreg_home` flag seems to have been dropped by accident from the test command. I've re-added it. Also renamed `libclang_dir` -> `llvm_dir` which was missed in an earlier change.

That's indeed an issue but the toolchain allows to specify where to find the JDKs via properties


org.gradle.java.installations.fromEnv=JDK18,JDK19


org.gradle.java.installations.paths=/custom/path/jdk18,/custom/path/jdk19


The benefit is that there's no collusion with `JAVA_HOME` which may be used by something else, in particular Gradle.

----

>From what I understand Gradle team is working to provide a better toolchain selection, but it is not there yet.

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

PR: https://git.openjdk.java.net/jextract/pull/9

From mcimadamore at openjdk.java.net  Tue Mar 29 09:58:07 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 29 Mar 2022 09:58:07 GMT
Subject: RFR: 7903136: Don't require jdk18_home to be set in jextract
 gradle build
In-Reply-To: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
References: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
Message-ID: <FeNqx26e1tCScXoAw9K8BoNokgqgQncUojFp5C3Q83E=.a90137f2-5e62-4d9f-a053-f9ac5770abe0@github.com>

On Mon, 28 Mar 2022 16:02:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Drop the requirement to set `jdk18_home` in the gradle build, and rely instead on `JAVA_HOME` being set to JDK 18.
> 
> I've also updated the build instructions. The `-Pjtreg_home` flag seems to have been dropped by accident from the test command. I've re-added it. Also renamed `libclang_dir` -> `llvm_dir` which was missed in an earlier change.

I've tried `org.gradle.java.installations.paths` and that indeed helps finding a non-GA version of the JDK that is locally installed.

Assuming we can make everything work (e.g. moditect plugin does not honor toolchain AFAIK), and assuming that ides work better with toolchains, that works for me. I would disable auto-provisioning out of the box though (users can re-enable locally).

> That's indeed an issue but the toolchain allows to specify where to find the JDKs via properties
> 
> ```ini
> org.gradle.java.installations.fromEnv=JDK18,JDK19
> ```
> 
> ```ini
> org.gradle.java.installations.paths=/custom/path/jdk18,/custom/path/jdk19
> ```
> 
> The benefit is that there's no collusion with `JAVA_HOME` which may be used by something else, in particular Gradle.
> 
> From what I understand Gradle team is working to provide a better toolchain selection, but it is not there yet.

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

PR: https://git.openjdk.java.net/jextract/pull/9

From duke at openjdk.java.net  Tue Mar 29 10:14:59 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Tue, 29 Mar 2022 10:14:59 GMT
Subject: RFR: Update Readme with macOs specifics [v2]
In-Reply-To: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
Message-ID: <q_e0XBRLTGKS0xu44pDPBckk8gpY2Mp_DGmAC565ahQ=.55fded51-e6b7-42a5-862b-afc2c9ec1800@github.com>

> The macOs libclang location as well as build output differ enough to warrant specific information. In particular the use of the XCode based path to find the libclang is not an easy find. The output also makes use of jpackage with `app-image` type, but the macOs _.app_ layout different enough on macOs.

Brice Dutheil has updated the pull request incrementally with one additional commit since the last revision:

  Fix review comments

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/10/files
  - new: https://git.openjdk.java.net/jextract/pull/10/files/11c00131..c3a072a5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=10&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=10&range=00-01

  Stats: 11 lines in 1 file changed: 9 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jextract/pull/10.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/10/head:pull/10

PR: https://git.openjdk.java.net/jextract/pull/10

From duke at openjdk.java.net  Tue Mar 29 10:15:01 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Tue, 29 Mar 2022 10:15:01 GMT
Subject: RFR: Update Readme with macOs specifics [v2]
In-Reply-To: <q_e0XBRLTGKS0xu44pDPBckk8gpY2Mp_DGmAC565ahQ=.55fded51-e6b7-42a5-862b-afc2c9ec1800@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <q_e0XBRLTGKS0xu44pDPBckk8gpY2Mp_DGmAC565ahQ=.55fded51-e6b7-42a5-862b-afc2c9ec1800@github.com>
Message-ID: <OohpWRaouDLw4wDtPaoAKRObY0ckA--Ouna5xPcL7gM=.8baca1c2-6c44-415c-af68-614d6665691a@github.com>

On Tue, 29 Mar 2022 10:10:33 GMT, Brice Dutheil <duke at openjdk.java.net> wrote:

>> The macOs libclang location as well as build output differ enough to warrant specific information. In particular the use of the XCode based path to find the libclang is not an easy find. The output also makes use of jpackage with `app-image` type, but the macOs _.app_ layout different enough on macOs.
>
> Brice Dutheil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix review comments

README.md line 54:

> 52: 
> 53: ```sh
> 54: $ sh ./gradlew -Pjdk18_home=<jdk18_home_dir> -Pllvm_home=<libclang_dir> -Pjtreg_home=<jtreg_home> jtreg

I noticed `jtreg` task also required this property to be set.

However I do have a question about which version of jtreg should be used, as a convenience I downloaded jtreg6 from Aleksey Shipil?v https://builds.shipilev.net/jtreg/

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

PR: https://git.openjdk.java.net/jextract/pull/10

From duke at openjdk.java.net  Tue Mar 29 10:32:58 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Tue, 29 Mar 2022 10:32:58 GMT
Subject: RFR: Update Readme with macOs specifics [v2]
In-Reply-To: <q_e0XBRLTGKS0xu44pDPBckk8gpY2Mp_DGmAC565ahQ=.55fded51-e6b7-42a5-862b-afc2c9ec1800@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <q_e0XBRLTGKS0xu44pDPBckk8gpY2Mp_DGmAC565ahQ=.55fded51-e6b7-42a5-862b-afc2c9ec1800@github.com>
Message-ID: <9B9hQUmr3G3cVlrbmNWl8temaQHAzDMCk92HmMTxVA4=.296093b4-8fd7-4ed4-93fe-239d67ddb9b4@github.com>

On Tue, 29 Mar 2022 10:14:59 GMT, Brice Dutheil <duke at openjdk.java.net> wrote:

>> The macOs libclang location as well as build output differ enough to warrant specific information. In particular the use of the XCode based path to find the libclang is not an easy find. The output also makes use of jpackage with `app-image` type, but the macOs _.app_ layout different enough on macOs.
>
> Brice Dutheil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix review comments

So I have enclosed the alternative local installation in a `details` block. 
>From what I have done so far using `clean verify` tasks for all alternative works well, and the `jextract` command works well too.

* `sh ./gradlew -Pjdk18_home=$(asdf where java corretto-18.0.0.37.1) -Pllvm_home=$(brew --prefix llvm) clean verify`
* `sh ./gradlew -Pjdk18_home=$(asdf where java corretto-18.0.0.37.1) -Pllvm_home=/Library/Developer/CommandLineTools/usr/ clean verify`
* `sh ./gradlew -Pjdk18_home=$(asdf where java corretto-18.0.0.37.1) -Pllvm_home=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/ clean verify`
* `sh ./gradlew -Pjdk18_home=$(asdf where java corretto-18.0.0.37.1) -Pllvm_home=$HOME/Downloads/clang+llvm-14.0.0-x86_64-apple-darwin clean verify`


However `jtreg` doesn't pass in my current setup., I noticed this in the JTwork reports.


java.lang.UnsupportedOperationException: The Security Manager is deprecated and will be removed in a future release
	at java.base/java.lang.System.setSecurityManager(System.java:416)
	at com.sun.javatest.regtest.agent.RegressionSecurityManager.install(RegressionSecurityManager.java:56)
	at com.sun.javatest.regtest.agent.AgentServer.<init>(AgentServer.java:211)
	at com.sun.javatest.regtest.agent.AgentServer.main(AgentServer.java:70)
result: Error. Agent communication error: java.net.SocketException: Connection reset; check console log for any additional details


I don't quite know about `jtreg` at this time, so I'm not sure what to do with this yet.

<details><summary><code>sh ./gradlew -Pjdk18_home=$(asdf where java corretto-18.0.0.37.1) -Pllvm_home=$HOME/Downloads/clang+llvm-14.0.0-x86_64-apple-darwin -Pjtreg_home=$HOME/Downloads/jtreg clean jtreg</code></summary>


$ sh ./gradlew -Pjdk18_home=$(asdf where java corretto-18.0.0.37.1) -Pllvm_home=$HOME/Downloads/clang+llvm-14.0.0-x86_64-apple-darwin -Pjtreg_home=$HOME/Downloads/jtreg clean jtreg

> Task :cmakeConfigure
-- The C compiler identification is AppleClang 13.1.6.13160021
-- The CXX compiler identification is AppleClang 13.1.6.13160021
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Processing test lib: /Users/brice.dutheil/opensource/jextract/test/../test/generator/funcPointerInvokers/libFunc.c
-- Lib name: Func
-- Processing test lib: /Users/brice.dutheil/opensource/jextract/test/../test/generator/test8239918/libTest8239918.c
-- Lib name: Test8239918
-- Processing test lib: /Users/brice.dutheil/opensource/jextract/test/../test/generator/test8244938/libTest8244938.c
-- Lib name: Test8244938
-- Processing test lib: /Users/brice.dutheil/opensource/jextract/test/../test/generator/test8244959/libPrintf.c
-- Lib name: Printf
-- Processing test lib: /Users/brice.dutheil/opensource/jextract/test/../test/generator/test8245003/libTest8245003.c
-- Lib name: Test8245003
-- Processing test lib: /Users/brice.dutheil/opensource/jextract/test/../test/generator/test8246341/libTest8246341.c
-- Lib name: Test8246341
-- Processing test lib: /Users/brice.dutheil/opensource/jextract/test/../test/generator/test8246400/libTest8246400.c
-- Lib name: Test8246400
-- Processing test lib: /Users/brice.dutheil/opensource/jextract/test/../test/generator/test8249757/libTest8249757.c
-- Lib name: Test8249757
-- Processing test lib: /Users/brice.dutheil/opensource/jextract/test/../test/generator/test8252016/libVSPrintf.c
-- Lib name: VSPrintf
-- Processing test lib: /Users/brice.dutheil/opensource/jextract/test/../test/generator/test8252121/libArrayparam.c
-- Lib name: Arrayparam
-- Processing test lib: /Users/brice.dutheil/opensource/jextract/test/../test/generator/test8253102/libTest8253102.c
-- Lib name: Test8253102
-- Processing test lib: /Users/brice.dutheil/opensource/jextract/test/../test/generator/test8257892/libUnsupported.c
-- Lib name: Unsupported
-- Processing test lib: /Users/brice.dutheil/opensource/jextract/test/../test/generator/test8258605/libFuncParam.c
-- Lib name: FuncParam
-- Processing test lib: /Users/brice.dutheil/opensource/jextract/test/../test/generator/test8261511/libTest8261511.c
-- Lib name: Test8261511
-- Processing test lib: /Users/brice.dutheil/opensource/jextract/test/../test/generator/testFunctionPointer/libFuncPtr.c
-- Lib name: FuncPtr
-- Processing test lib: /Users/brice.dutheil/opensource/jextract/test/../test/generator/testStruct/libStruct.c
-- Lib name: Struct
-- Processing test lib: /Users/brice.dutheil/opensource/jextract/test/../test/java/org/openjdk/jextract/test/toolprovider/libExamples.c
-- Lib name: Examples
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/brice.dutheil/opensource/jextract/build/testlib-build

> Task :cmakeBuild
[  2%] Building C object CMakeFiles/Func.dir/Users/brice.dutheil/opensource/jextract/test/generator/funcPointerInvokers/libFunc.c.o
[  5%] Linking C shared library libFunc.dylib
[  5%] Built target Func
[  8%] Building C object CMakeFiles/Test8239918.dir/Users/brice.dutheil/opensource/jextract/test/generator/test8239918/libTest8239918.c.o
[ 11%] Linking C shared library libTest8239918.dylib
[ 11%] Built target Test8239918
[ 14%] Building C object CMakeFiles/Test8244938.dir/Users/brice.dutheil/opensource/jextract/test/generator/test8244938/libTest8244938.c.o
[ 17%] Linking C shared library libTest8244938.dylib
[ 17%] Built target Test8244938
[ 20%] Building C object CMakeFiles/Printf.dir/Users/brice.dutheil/opensource/jextract/test/generator/test8244959/libPrintf.c.o
[ 23%] Linking C shared library libPrintf.dylib
[ 23%] Built target Printf
[ 26%] Building C object CMakeFiles/Test8245003.dir/Users/brice.dutheil/opensource/jextract/test/generator/test8245003/libTest8245003.c.o
[ 29%] Linking C shared library libTest8245003.dylib
[ 29%] Built target Test8245003
[ 32%] Building C object CMakeFiles/Test8246341.dir/Users/brice.dutheil/opensource/jextract/test/generator/test8246341/libTest8246341.c.o
[ 35%] Linking C shared library libTest8246341.dylib
[ 35%] Built target Test8246341
[ 38%] Building C object CMakeFiles/Test8246400.dir/Users/brice.dutheil/opensource/jextract/test/generator/test8246400/libTest8246400.c.o
[ 41%] Linking C shared library libTest8246400.dylib
[ 41%] Built target Test8246400
[ 44%] Building C object CMakeFiles/Test8249757.dir/Users/brice.dutheil/opensource/jextract/test/generator/test8249757/libTest8249757.c.o
[ 47%] Linking C shared library libTest8249757.dylib
[ 47%] Built target Test8249757
[ 50%] Building C object CMakeFiles/VSPrintf.dir/Users/brice.dutheil/opensource/jextract/test/generator/test8252016/libVSPrintf.c.o
[ 52%] Linking C shared library libVSPrintf.dylib
[ 52%] Built target VSPrintf
[ 55%] Building C object CMakeFiles/Arrayparam.dir/Users/brice.dutheil/opensource/jextract/test/generator/test8252121/libArrayparam.c.o
[ 58%] Linking C shared library libArrayparam.dylib
[ 58%] Built target Arrayparam
[ 61%] Building C object CMakeFiles/Test8253102.dir/Users/brice.dutheil/opensource/jextract/test/generator/test8253102/libTest8253102.c.o
[ 64%] Linking C shared library libTest8253102.dylib
[ 64%] Built target Test8253102
[ 67%] Building C object CMakeFiles/Unsupported.dir/Users/brice.dutheil/opensource/jextract/test/generator/test8257892/libUnsupported.c.o
[ 70%] Linking C shared library libUnsupported.dylib
[ 70%] Built target Unsupported
[ 73%] Building C object CMakeFiles/FuncParam.dir/Users/brice.dutheil/opensource/jextract/test/generator/test8258605/libFuncParam.c.o
[ 76%] Linking C shared library libFuncParam.dylib
[ 76%] Built target FuncParam
[ 79%] Building C object CMakeFiles/Test8261511.dir/Users/brice.dutheil/opensource/jextract/test/generator/test8261511/libTest8261511.c.o
[ 82%] Linking C shared library libTest8261511.dylib
[ 82%] Built target Test8261511
[ 85%] Building C object CMakeFiles/FuncPtr.dir/Users/brice.dutheil/opensource/jextract/test/generator/testFunctionPointer/libFuncPtr.c.o
[ 88%] Linking C shared library libFuncPtr.dylib
[ 88%] Built target FuncPtr
[ 91%] Building C object CMakeFiles/Struct.dir/Users/brice.dutheil/opensource/jextract/test/generator/testStruct/libStruct.c.o
[ 94%] Linking C shared library libStruct.dylib
[ 94%] Built target Struct
[ 97%] Building C object CMakeFiles/Examples.dir/Users/brice.dutheil/opensource/jextract/test/java/org/openjdk/jextract/test/toolprovider/libExamples.c.o
[100%] Linking C shared library libExamples.dylib
[100%] Built target Examples
Install the project...
-- Install configuration: "Release"
-- Installing: /Users/brice.dutheil/opensource/jextract/build/testlib-install/lib/libFunc.dylib
-- Installing: /Users/brice.dutheil/opensource/jextract/build/testlib-install/lib/libTest8239918.dylib
-- Installing: /Users/brice.dutheil/opensource/jextract/build/testlib-install/lib/libTest8244938.dylib
-- Installing: /Users/brice.dutheil/opensource/jextract/build/testlib-install/lib/libPrintf.dylib
-- Installing: /Users/brice.dutheil/opensource/jextract/build/testlib-install/lib/libTest8245003.dylib
-- Installing: /Users/brice.dutheil/opensource/jextract/build/testlib-install/lib/libTest8246341.dylib
-- Installing: /Users/brice.dutheil/opensource/jextract/build/testlib-install/lib/libTest8246400.dylib
-- Installing: /Users/brice.dutheil/opensource/jextract/build/testlib-install/lib/libTest8249757.dylib
-- Installing: /Users/brice.dutheil/opensource/jextract/build/testlib-install/lib/libVSPrintf.dylib
-- Installing: /Users/brice.dutheil/opensource/jextract/build/testlib-install/lib/libArrayparam.dylib
-- Installing: /Users/brice.dutheil/opensource/jextract/build/testlib-install/lib/libTest8253102.dylib
-- Installing: /Users/brice.dutheil/opensource/jextract/build/testlib-install/lib/libUnsupported.dylib
-- Installing: /Users/brice.dutheil/opensource/jextract/build/testlib-install/lib/libFuncParam.dylib
-- Installing: /Users/brice.dutheil/opensource/jextract/build/testlib-install/lib/libTest8261511.dylib
-- Installing: /Users/brice.dutheil/opensource/jextract/build/testlib-install/lib/libFuncPtr.dylib
-- Installing: /Users/brice.dutheil/opensource/jextract/build/testlib-install/lib/libStruct.dylib
-- Installing: /Users/brice.dutheil/opensource/jextract/build/testlib-install/lib/libExamples.dylib

> Task :compileJava
warning: using incubating module(s): jdk.incubator.foreign
1 warning

> Task :verify
WARNING: Using incubator modules: jdk.incubator.foreign

> Task :jtreg
Directory "JTwork" not found: creating
Directory "JTreport" not found: creating
WARNING: Using incubator modules: jdk.incubator.foreign
WARNING: Using incubator modules: jdk.incubator.foreign
Error:  generator/funcPointerInvokers/TestFuncPointerInvokers.java#classes
Error:  generator/funcPointerInvokers/TestFuncPointerInvokers.java#sources
Error:  generator/test8239918/LibTest8239918Test.java#sources
Error:  generator/test8244412/LibTest8244412Test.java#classes
Error:  generator/test8240373/Lib8240373Test.java#sources
Error:  generator/test8244412/LibTest8244412Test.java#sources
Error:  generator/test8240373/Lib8240373Test.java#classes
Error:  generator/test8239918/LibTest8239918Test.java#classes
Error:  generator/test8246341/LibTest8246341Test.java#classes
Error:  generator/test8245003/Test8245003.java#sources
Error:  generator/test8245003/Test8245003.java#classes
Error:  generator/test8244959/Test8244959.java#sources
Error:  generator/test8244959/Test8244959.java#classes
Error:  generator/test8244938/Test8244938.java#sources
Error:  generator/test8244938/Test8244938.java#classes
Error:  generator/test8252016/Test8252016.java#sources
Error:  generator/test8252016/Test8252016.java#classes
Error:  generator/test8249757/LibTest8249757Test.java#sources
Error:  generator/test8249757/LibTest8249757Test.java#classes
Error:  generator/test8246400/LibTest8246400Test.java#sources
Error:  generator/test8246400/LibTest8246400Test.java#classes
Error:  generator/test8246341/LibTest8246341Test.java#sources
Error:  generator/test8253390/LibTest8253390Test.java#classes
Error:  generator/test8253102/LibTest8253102Test.java#sources
Error:  generator/test8253102/LibTest8253102Test.java#classes
Error:  generator/test8252465/LibTest8252465Test.java#sources
Error:  generator/test8252465/LibTest8252465Test.java#classes
Error:  generator/test8252121/Test8252121.java#sources
Error:  generator/test8252121/Test8252121.java#classes
Error:  generator/test8258605/LibTest8258605Test.java#sources
Error:  generator/test8258605/LibTest8258605Test.java#classes
Error:  generator/test8257892/LibUnsupportedTest.java#sources
Error:  generator/test8257892/LibUnsupportedTest.java#classes
Error:  generator/test8254983/LibTest8254983Test.java#sources
Error:  generator/test8254983/LibTest8254983Test.java#classes
Error:  generator/test8253390/LibTest8253390Test.java#sources
Error:  generator/testFunctionPointer/LibFuncPtrTest.java#classes
Error:  generator/test8282235/Test8282235.java
Error:  generator/test8281764/Test8281764.java
Error:  generator/test8261511/Test8261511.java#sources
Error:  generator/test8261511/Test8261511.java#classes
Error:  generator/test8259473/LibTest8259473Test.java#sources
Error:  generator/test8259473/LibTest8259473Test.java#classes
Error:  java/org/openjdk/jextract/test/api/SmokeTest.java
Error:  java/org/openjdk/jextract/test/api/JextractApiTestBase.java
Error:  generator/testStruct/LibStructTest.java#sources
Error:  generator/testStruct/LibStructTest.java#classes
Error:  generator/testGlobalRedefinition/TestGlobalRedefinition.java#sources
Error:  generator/testGlobalRedefinition/TestGlobalRedefinition.java#classes
Error:  generator/testFunctionPointer/LibFuncPtrTest.java#sources
Error:  java/org/openjdk/jextract/test/api/TestMacros.java
Error:  java/org/openjdk/jextract/test/api/TestAttributes.java
Error:  java/org/openjdk/jextract/test/api/Test8241650.java
Error:  java/org/openjdk/jextract/test/api/Test8240853.java
Error:  java/org/openjdk/jextract/test/api/Test8240372.java
Error:  java/org/openjdk/jextract/test/api/Test8239490.java
Error:  java/org/openjdk/jextract/test/api/Test8238712.java
Error:  java/org/openjdk/jextract/test/toolprovider/JextractToolRunner.java
Error:  java/org/openjdk/jextract/test/toolprovider/JextractToolProviderTest.java
Error:  java/org/openjdk/jextract/test/toolprovider/IncompleteArrayTest.java
Error:  java/org/openjdk/jextract/test/toolprovider/ConstantsTest.java
Error:  java/org/openjdk/jextract/test/toolprovider/BadBitfieldTest.java
Error:  java/org/openjdk/jextract/test/api/TestTypedef.java
Error:  java/org/openjdk/jextract/test/api/TestNestedBitfields.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8245767.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8244412.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8240811.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8240752.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8240657.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8240181.java
Error:  java/org/openjdk/jextract/test/toolprovider/RepeatedDeclsTest.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8258405.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8258223.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8251943.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8249300.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8249290.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8248474.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8248415.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8262117.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8261893.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8261578.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8260929.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8260717.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8260705.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8260344.java
Error:  java/org/openjdk/jextract/test/toolprovider/TestNested.java
Error:  java/org/openjdk/jextract/test/toolprovider/TestFilters.java
Error:  java/org/openjdk/jextract/test/toolprovider/TestClassGeneration.java
Error:  java/org/openjdk/jextract/test/toolprovider/TestAttributedPointerTypedef.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8262851.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8262825.java
Error:  java/org/openjdk/jextract/test/toolprovider/Test8262733.java
Error:  java/org/openjdk/jextract/test/TestUtils.java
Error:  java/org/openjdk/jextract/test/toolprovider/UniondeclTest.java
Error:  java/org/openjdk/jextract/test/toolprovider/TestTypedefIsFunctionProto.java
Error:  java/org/openjdk/jextract/test/toolprovider/TestSplit.java
Test results: error: 96
Report written to /Users/brice.dutheil/opensource/jextract/build/JTreport/html/report.html
Results written to /Users/brice.dutheil/opensource/jextract/build/JTwork
Error: Some tests failed or other problems occurred.

> Task :jtreg FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':jtreg'.
> Process 'command '/Users/brice.dutheil/.asdf/installs/java/corretto-17.0.2.8.1/bin/java'' finished with non-zero exit value 3

* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

* Get more help at https://help.gradle.org

BUILD FAILED in 53s
16 actionable tasks: 16 executed


</details>

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

PR: https://git.openjdk.java.net/jextract/pull/10

From mcimadamore at openjdk.java.net  Tue Mar 29 10:33:00 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 29 Mar 2022 10:33:00 GMT
Subject: RFR: Update Readme with macOs specifics [v2]
In-Reply-To: <OohpWRaouDLw4wDtPaoAKRObY0ckA--Ouna5xPcL7gM=.8baca1c2-6c44-415c-af68-614d6665691a@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <q_e0XBRLTGKS0xu44pDPBckk8gpY2Mp_DGmAC565ahQ=.55fded51-e6b7-42a5-862b-afc2c9ec1800@github.com>
 <OohpWRaouDLw4wDtPaoAKRObY0ckA--Ouna5xPcL7gM=.8baca1c2-6c44-415c-af68-614d6665691a@github.com>
Message-ID: <FSOzQGoWmkCxtyTJtlTGMKC319SsSNCS0JWByBcC190=.dab0e0cc-cd61-499b-b57f-8d0a90d92f25@github.com>

On Tue, 29 Mar 2022 10:10:33 GMT, Brice Dutheil <duke at openjdk.java.net> wrote:

>> Brice Dutheil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix review comments
>
> README.md line 54:
> 
>> 52: 
>> 53: ```sh
>> 54: $ sh ./gradlew -Pjdk18_home=<jdk18_home_dir> -Pllvm_home=<libclang_dir> -Pjtreg_home=<jtreg_home> jtreg
> 
> I noticed `jtreg` task also required this property to be set.
> 
> However I do have a question about which version of jtreg should be used, as a convenience I downloaded jtreg6 from Aleksey Shipil?v https://builds.shipilev.net/jtreg/

that version of jtreg should be ok

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

PR: https://git.openjdk.java.net/jextract/pull/10

From mcimadamore at openjdk.java.net  Tue Mar 29 10:48:05 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 29 Mar 2022 10:48:05 GMT
Subject: RFR: Update Readme with macOs specifics [v2]
In-Reply-To: <q_e0XBRLTGKS0xu44pDPBckk8gpY2Mp_DGmAC565ahQ=.55fded51-e6b7-42a5-862b-afc2c9ec1800@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <q_e0XBRLTGKS0xu44pDPBckk8gpY2Mp_DGmAC565ahQ=.55fded51-e6b7-42a5-862b-afc2c9ec1800@github.com>
Message-ID: <mwFPCWRfxi919_SnPGWBHREpZNkrgfbZWZ89_2ysv5A=.0b78d292-523a-4d6f-be5c-b20ab7059535@github.com>

On Tue, 29 Mar 2022 10:14:59 GMT, Brice Dutheil <duke at openjdk.java.net> wrote:

>> The macOs libclang location as well as build output differ enough to warrant specific information. In particular the use of the XCode based path to find the libclang is not an easy find. The output also makes use of jpackage with `app-image` type, but the macOs _.app_ layout different enough on macOs.
>
> Brice Dutheil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix review comments

README.md line 15:

> 13: ```
> 14: 
> 15: <details><summary>Using a local installation of LLVM</summary>

Can we do this in bold, and also perhaps use the quote mechanism - e.g.

> <details><summary><b>Using a local installation of LLVM</b></summary>Some text</summary>

README.md line 28:

> 26: </details>
> 27: 
> 28: After building, there should be a new `jextract` folder under `build` (the contents and the name of this folder might vary slightly depending on the platform, e.g. on macOs the folder is `jextract.app`) :

Do you think it is still necessary to provide specific details about macOs here (and below) ?

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

PR: https://git.openjdk.java.net/jextract/pull/10

From mcimadamore at openjdk.java.net  Tue Mar 29 10:48:06 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 29 Mar 2022 10:48:06 GMT
Subject: RFR: Update Readme with macOs specifics [v2]
In-Reply-To: <mwFPCWRfxi919_SnPGWBHREpZNkrgfbZWZ89_2ysv5A=.0b78d292-523a-4d6f-be5c-b20ab7059535@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <q_e0XBRLTGKS0xu44pDPBckk8gpY2Mp_DGmAC565ahQ=.55fded51-e6b7-42a5-862b-afc2c9ec1800@github.com>
 <mwFPCWRfxi919_SnPGWBHREpZNkrgfbZWZ89_2ysv5A=.0b78d292-523a-4d6f-be5c-b20ab7059535@github.com>
Message-ID: <Y4uKaU_YWfl6dorAoWBXsAA3uDtlNR1SO-tLIEaiIBg=.a11345e0-9e94-4c4a-aa78-c639cf4321c4@github.com>

On Tue, 29 Mar 2022 10:41:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Brice Dutheil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix review comments
>
> README.md line 15:
> 
>> 13: ```
>> 14: 
>> 15: <details><summary>Using a local installation of LLVM</summary>
> 
> Can we do this in bold, and also perhaps use the quote mechanism - e.g.
> 
>> <details><summary><b>Using a local installation of LLVM</b></summary>Some text</summary>

> Can we do this in bold, and also perhaps use the quote mechanism - e.g.
> 
> > Using a local installation of LLVMSome text

The above was done like this:


> <details><summary><b>Using a local installation of LLVM</b></summary>Some text</summary>

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

PR: https://git.openjdk.java.net/jextract/pull/10

From duke at openjdk.java.net  Tue Mar 29 10:48:09 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Tue, 29 Mar 2022 10:48:09 GMT
Subject: RFR: Update Readme with macOs specifics [v2]
In-Reply-To: <FSOzQGoWmkCxtyTJtlTGMKC319SsSNCS0JWByBcC190=.dab0e0cc-cd61-499b-b57f-8d0a90d92f25@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <q_e0XBRLTGKS0xu44pDPBckk8gpY2Mp_DGmAC565ahQ=.55fded51-e6b7-42a5-862b-afc2c9ec1800@github.com>
 <OohpWRaouDLw4wDtPaoAKRObY0ckA--Ouna5xPcL7gM=.8baca1c2-6c44-415c-af68-614d6665691a@github.com>
 <FSOzQGoWmkCxtyTJtlTGMKC319SsSNCS0JWByBcC190=.dab0e0cc-cd61-499b-b57f-8d0a90d92f25@github.com>
Message-ID: <L93TjTi0HtJjAqgH8C-xjQMLA13kJ1LwPGSLuDJ3Z8g=.59ed9af4-674e-4821-af50-c0ec649c07d5@github.com>

On Tue, 29 Mar 2022 10:29:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> README.md line 54:
>> 
>>> 52: 
>>> 53: ```sh
>>> 54: $ sh ./gradlew -Pjdk18_home=<jdk18_home_dir> -Pllvm_home=<libclang_dir> -Pjtreg_home=<jtreg_home> jtreg
>> 
>> I noticed `jtreg` task also required this property to be set.
>> 
>> However I do have a question about which version of jtreg should be used, as a convenience I downloaded jtreg6 from Aleksey Shipil?v https://builds.shipilev.net/jtreg/
>
> that version of jtreg should be ok

I hesitated to add this link since I don't if this ok to link to individual builds, even if this is Aleksey Shipil?v.

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

PR: https://git.openjdk.java.net/jextract/pull/10

From duke at openjdk.java.net  Tue Mar 29 11:01:10 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Tue, 29 Mar 2022 11:01:10 GMT
Subject: RFR: Update Readme with macOs specifics [v2]
In-Reply-To: <mwFPCWRfxi919_SnPGWBHREpZNkrgfbZWZ89_2ysv5A=.0b78d292-523a-4d6f-be5c-b20ab7059535@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <q_e0XBRLTGKS0xu44pDPBckk8gpY2Mp_DGmAC565ahQ=.55fded51-e6b7-42a5-862b-afc2c9ec1800@github.com>
 <mwFPCWRfxi919_SnPGWBHREpZNkrgfbZWZ89_2ysv5A=.0b78d292-523a-4d6f-be5c-b20ab7059535@github.com>
Message-ID: <pKvGvUys-IOxqpgMEjJQWwYT0Qa3m2A1iu8_zOQNNkA=.f9e9790d-0a4f-41d3-b307-0c6b9574c258@github.com>

On Tue, 29 Mar 2022 10:31:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Brice Dutheil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix review comments
>
> README.md line 28:
> 
>> 26: </details>
>> 27: 
>> 28: After building, there should be a new `jextract` folder under `build` (the contents and the name of this folder might vary slightly depending on the platform, e.g. on macOs the folder is `jextract.app`) :
> 
> Do you think it is still necessary to provide specific details about macOs here (and below) ?

Yes I think this is necessary as long as this is packaged with `jpackage`, because not everyone is accustomed ta macOs application layout.

In my opinion jpackage does a very neat job to pack desktop application. But for command line interactions this is less practical in my opinion. I think this might complicate a bit the consumption of this command line tool, requiring to adapt the actual path, that unless a workaround is set up (a symbolic link, or adding `.../jextract.app/Contents/MacOS` to `PATH`).


Ultimately I think a `.tar.gz` distribution would be better for consumption, but I don't know to do that (and elegantly) at this time.

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

PR: https://git.openjdk.java.net/jextract/pull/10

From duke at openjdk.java.net  Tue Mar 29 11:12:55 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Tue, 29 Mar 2022 11:12:55 GMT
Subject: RFR: 7903136: Don't require jdk18_home to be set in jextract
 gradle build
In-Reply-To: <FeNqx26e1tCScXoAw9K8BoNokgqgQncUojFp5C3Q83E=.a90137f2-5e62-4d9f-a053-f9ac5770abe0@github.com>
References: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
 <FeNqx26e1tCScXoAw9K8BoNokgqgQncUojFp5C3Q83E=.a90137f2-5e62-4d9f-a053-f9ac5770abe0@github.com>
Message-ID: <xg7CS2Wvel_ZhJaoZCsLobpZUUjNh8ARksmZVx0lqKo=.c3cecb34-2bd0-4505-86ca-ddef73abb35c@github.com>

On Tue, 29 Mar 2022 09:54:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I would disable auto-provisioning out of the box though

That makes sense.

> Assuming we can make everything work (e.g. moditect plugin does not honor toolchain AFAIK)

I've never used moditect, and I haven't looked up alternatives either, but it might be possible such tools have options like `jvm`, `jdk`, `jdkHome`.

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

PR: https://git.openjdk.java.net/jextract/pull/9

From duke at openjdk.java.net  Tue Mar 29 11:16:45 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Tue, 29 Mar 2022 11:16:45 GMT
Subject: RFR: Update Readme with macOs specifics [v3]
In-Reply-To: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
Message-ID: <YUVQlcKBPiCpaOc02ihJXyAePnv5uS4gKB6yMUWlDrQ=.007b998b-192d-472a-8ccb-06c89a1cc797@github.com>

> The macOs libclang location as well as build output differ enough to warrant specific information. In particular the use of the XCode based path to find the libclang is not an easy find. The output also makes use of jpackage with `app-image` type, but the macOs _.app_ layout different enough on macOs.

Brice Dutheil has updated the pull request incrementally with one additional commit since the last revision:

  Make local installation quoted

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/10/files
  - new: https://git.openjdk.java.net/jextract/pull/10/files/c3a072a5..baf128b7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=10&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=10&range=01-02

  Stats: 13 lines in 1 file changed: 2 ins; 1 del; 10 mod
  Patch: https://git.openjdk.java.net/jextract/pull/10.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/10/head:pull/10

PR: https://git.openjdk.java.net/jextract/pull/10

From duke at openjdk.java.net  Tue Mar 29 11:16:45 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Tue, 29 Mar 2022 11:16:45 GMT
Subject: RFR: Update Readme with macOs specifics [v2]
In-Reply-To: <Y4uKaU_YWfl6dorAoWBXsAA3uDtlNR1SO-tLIEaiIBg=.a11345e0-9e94-4c4a-aa78-c639cf4321c4@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <q_e0XBRLTGKS0xu44pDPBckk8gpY2Mp_DGmAC565ahQ=.55fded51-e6b7-42a5-862b-afc2c9ec1800@github.com>
 <mwFPCWRfxi919_SnPGWBHREpZNkrgfbZWZ89_2ysv5A=.0b78d292-523a-4d6f-be5c-b20ab7059535@github.com>
 <Y4uKaU_YWfl6dorAoWBXsAA3uDtlNR1SO-tLIEaiIBg=.a11345e0-9e94-4c4a-aa78-c639cf4321c4@github.com>
Message-ID: <6L9GIzKSy2Mhg3GUjMv10YOiIE2nWiDWWWmNZEJJ1NE=.8e5530ec-1df5-4041-beb5-776f909ac35c@github.com>

On Tue, 29 Mar 2022 10:41:50 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> README.md line 15:
>> 
>>> 13: ```
>>> 14: 
>>> 15: <details><summary>Using a local installation of LLVM</summary>
>> 
>> Can we do this in bold, and also perhaps use the quote mechanism - e.g.
>> 
>>> <details><summary><b>Using a local installation of LLVM</b></summary>Some text</summary>
>
>> Can we do this in bold, and also perhaps use the quote mechanism - e.g.
>> 
>> > Using a local installation of LLVMSome text
> 
> The above was done like this:
> 
> 
>> <details><summary><b>Using a local installation of LLVM</b></summary>Some text</summary>

Done

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

PR: https://git.openjdk.java.net/jextract/pull/10

From mcimadamore at openjdk.java.net  Tue Mar 29 11:16:46 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 29 Mar 2022 11:16:46 GMT
Subject: RFR: Update Readme with macOs specifics [v2]
In-Reply-To: <L93TjTi0HtJjAqgH8C-xjQMLA13kJ1LwPGSLuDJ3Z8g=.59ed9af4-674e-4821-af50-c0ec649c07d5@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <q_e0XBRLTGKS0xu44pDPBckk8gpY2Mp_DGmAC565ahQ=.55fded51-e6b7-42a5-862b-afc2c9ec1800@github.com>
 <OohpWRaouDLw4wDtPaoAKRObY0ckA--Ouna5xPcL7gM=.8baca1c2-6c44-415c-af68-614d6665691a@github.com>
 <FSOzQGoWmkCxtyTJtlTGMKC319SsSNCS0JWByBcC190=.dab0e0cc-cd61-499b-b57f-8d0a90d92f25@github.com>
 <L93TjTi0HtJjAqgH8C-xjQMLA13kJ1LwPGSLuDJ3Z8g=.59ed9af4-674e-4821-af50-c0ec649c07d5@github.com>
Message-ID: <HbY67OseEPGk8zDr869NBmhxFHMmFkWbe0475PlPMg4=.7104660e-98b1-4a61-9112-500f3cdce9d4@github.com>

On Tue, 29 Mar 2022 10:45:02 GMT, Brice Dutheil <duke at openjdk.java.net> wrote:

>> that version of jtreg should be ok
>
> I hesitated to add this link since I don't if this ok to link to individual builds, even if this is Aleksey Shipil?v.

Sorry, I think it's better not to have the link (I should have made that clearer).

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

PR: https://git.openjdk.java.net/jextract/pull/10

From duke at openjdk.java.net  Tue Mar 29 11:16:46 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Tue, 29 Mar 2022 11:16:46 GMT
Subject: RFR: Update Readme with macOs specifics [v2]
In-Reply-To: <HbY67OseEPGk8zDr869NBmhxFHMmFkWbe0475PlPMg4=.7104660e-98b1-4a61-9112-500f3cdce9d4@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <q_e0XBRLTGKS0xu44pDPBckk8gpY2Mp_DGmAC565ahQ=.55fded51-e6b7-42a5-862b-afc2c9ec1800@github.com>
 <OohpWRaouDLw4wDtPaoAKRObY0ckA--Ouna5xPcL7gM=.8baca1c2-6c44-415c-af68-614d6665691a@github.com>
 <FSOzQGoWmkCxtyTJtlTGMKC319SsSNCS0JWByBcC190=.dab0e0cc-cd61-499b-b57f-8d0a90d92f25@github.com>
 <L93TjTi0HtJjAqgH8C-xjQMLA13kJ1LwPGSLuDJ3Z8g=.59ed9af4-674e-4821-af50-c0ec649c07d5@github.com>
 <HbY67OseEPGk8zDr869NBmhxFHMmFkWbe0475PlPMg4=.7104660e-98b1-4a61-9112-500f3cdce9d4@github.com>
Message-ID: <HYNb15Ubu1JWY_dDu483Ry8Z-cAzo7V7ZCY260gj2dA=.3ca20ea6-8399-4723-afc5-4d6104f28c6d@github.com>

On Tue, 29 Mar 2022 11:08:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I hesitated to add this link since I don't if this ok to link to individual builds, even if this is Aleksey Shipil?v.
>
> Sorry, I think it's better not to have the link (I should have made that clearer).

No problem, that was what I assumed there.

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

PR: https://git.openjdk.java.net/jextract/pull/10

From mcimadamore at openjdk.java.net  Tue Mar 29 11:23:04 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 29 Mar 2022 11:23:04 GMT
Subject: RFR: Update Readme with macOs specifics [v2]
In-Reply-To: <pKvGvUys-IOxqpgMEjJQWwYT0Qa3m2A1iu8_zOQNNkA=.f9e9790d-0a4f-41d3-b307-0c6b9574c258@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <q_e0XBRLTGKS0xu44pDPBckk8gpY2Mp_DGmAC565ahQ=.55fded51-e6b7-42a5-862b-afc2c9ec1800@github.com>
 <mwFPCWRfxi919_SnPGWBHREpZNkrgfbZWZ89_2ysv5A=.0b78d292-523a-4d6f-be5c-b20ab7059535@github.com>
 <pKvGvUys-IOxqpgMEjJQWwYT0Qa3m2A1iu8_zOQNNkA=.f9e9790d-0a4f-41d3-b307-0c6b9574c258@github.com>
Message-ID: <LUCmeEwMesieK2VD-klyKT-dGIONN-PRu4fYCKIHTkQ=.9e7299d1-f437-449d-8cab-bfa27593a51e@github.com>

On Tue, 29 Mar 2022 10:57:35 GMT, Brice Dutheil <duke at openjdk.java.net> wrote:

>> README.md line 28:
>> 
>>> 26: </details>
>>> 27: 
>>> 28: After building, there should be a new `jextract` folder under `build` (the contents and the name of this folder might vary slightly depending on the platform, e.g. on macOs the folder is `jextract.app`) :
>> 
>> Do you think it is still necessary to provide specific details about macOs here (and below) ?
>
> Yes I think this is necessary as long as this is packaged with `jpackage`, because not everyone is accustomed ta macOs application layout.
> 
> In my opinion jpackage does a very neat job to pack desktop application. But for command line interactions this is less practical in my opinion. I think this might complicate a bit the consumption of this command line tool, requiring to adapt the actual path, that unless a workaround is set up (a symbolic link, or adding `.../jextract.app/Contents/MacOS` to `PATH`).
> 
> 
> Ultimately I think a `.tar.gz` distribution would be better for consumption, but I don't know to do that (and elegantly) at this time.

IMHO, the location of the jextract packaged application is not too important. In general I would expect users to build jextract once, and then install it in some well known path, at which point the name of the folder chosen by jpackage becomes irrelevant (which is why I'm not sure it's worth spending extra verbiage for this). What we might want to do is to add a post jpackage step which renames the folder to something consistent across platforms.

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

PR: https://git.openjdk.java.net/jextract/pull/10

From mcimadamore at openjdk.java.net  Tue Mar 29 11:56:04 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 29 Mar 2022 11:56:04 GMT
Subject: RFR: 7903136: Don't require jdk18_home to be set in jextract
 gradle build
In-Reply-To: <FeNqx26e1tCScXoAw9K8BoNokgqgQncUojFp5C3Q83E=.a90137f2-5e62-4d9f-a053-f9ac5770abe0@github.com>
References: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
 <FeNqx26e1tCScXoAw9K8BoNokgqgQncUojFp5C3Q83E=.a90137f2-5e62-4d9f-a053-f9ac5770abe0@github.com>
Message-ID: <06KXtYN2OFNpnO4gMdDWm7Dk7dbh-D6RbPSb6UjXIyY=.1dcde1eb-25d4-47c8-a6a8-dc9abf61e8d3@github.com>

On Tue, 29 Mar 2022 09:54:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> and assuming that ides work better with toolchains

That does not seem to be the case, unfortunately. That is, IDE needs the "installation path" property to be set - but, as for the current property, IntelliJ does not allow to easily add gradle properties. So, from an IDE usability perspective, using toolchains w/o auto-download is the same as what we currently have.

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

PR: https://git.openjdk.java.net/jextract/pull/9

From mcimadamore at openjdk.java.net  Tue Mar 29 11:56:06 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 29 Mar 2022 11:56:06 GMT
Subject: RFR: 7903136: Don't require jdk18_home to be set in jextract
 gradle build
In-Reply-To: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
References: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
Message-ID: <zp1ZkAw4ylEDVRxuo4EdAMhkooBhBPNXSxKvVCPiV5s=.91b20473-6b64-4c85-8275-8b5ec08b2514@github.com>

On Mon, 28 Mar 2022 16:02:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Drop the requirement to set `jdk18_home` in the gradle build, and rely instead on `JAVA_HOME` being set to JDK 18.
> 
> I've also updated the build instructions. The `-Pjtreg_home` flag seems to have been dropped by accident from the test command. I've re-added it. Also renamed `libclang_dir` -> `llvm_dir` which was missed in an earlier change.

After thinking some more, and having tried different things, it seems to me that, while alternatives are possible, nothing seems quite a slam dunk. The best and most consistent way to provide better user experience would be to add our own download logic of binaries in https://jdk.java.net - failing that, all solutions seem to suffer from some pros and cons - which don't make them a big enough improvement over the status quo, IMHO.

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

PR: https://git.openjdk.java.net/jextract/pull/9

From jvernee at openjdk.java.net  Tue Mar 29 13:04:21 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 29 Mar 2022 13:04:21 GMT
Subject: RFR: Update Readme with macOs specifics [v3]
In-Reply-To: <YUVQlcKBPiCpaOc02ihJXyAePnv5uS4gKB6yMUWlDrQ=.007b998b-192d-472a-8ccb-06c89a1cc797@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <YUVQlcKBPiCpaOc02ihJXyAePnv5uS4gKB6yMUWlDrQ=.007b998b-192d-472a-8ccb-06c89a1cc797@github.com>
Message-ID: <xQM183QoYbM0EBwiIAQZgpji8leRdCu-JAtstXRwtDg=.cfdedbc4-e9dd-4bb4-905f-41f645b89848@github.com>

On Tue, 29 Mar 2022 11:16:45 GMT, Brice Dutheil <duke at openjdk.java.net> wrote:

>> The macOs libclang location as well as build output differ enough to warrant specific information. In particular the use of the XCode based path to find the libclang is not an easy find. The output also makes use of jpackage with `app-image` type, but the macOs _.app_ layout different enough on macOs.
>
> Brice Dutheil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make local installation quoted

One minor typo. Otherwise this looks good to me.

README.md line 18:

> 16: > <details><summary><strong>Using a local installation of LLVM</strong></summary>
> 17: > 
> 18: > While the recommanded way is to use a [release from the LLVM project](https://releases.llvm.org/download.html),

Small typo here
Suggestion:

> While the recommended way is to use a [release from the LLVM project](https://releases.llvm.org/download.html),

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

Marked as reviewed by jvernee (no project role).

PR: https://git.openjdk.java.net/jextract/pull/10

From duke at openjdk.java.net  Tue Mar 29 13:15:46 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Tue, 29 Mar 2022 13:15:46 GMT
Subject: RFR: Update Readme with macOs specifics [v4]
In-Reply-To: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
Message-ID: <LjL7M6tHWxeoUKU9v6Y7dlkuRYLq0qJISHM-pp8GkHg=.b9ac2346-d5cc-4ba2-a0ed-ee75a96b2730@github.com>

> The macOs libclang location as well as build output differ enough to warrant specific information. In particular the use of the XCode based path to find the libclang is not an easy find. The output also makes use of jpackage with `app-image` type, but the macOs _.app_ layout different enough on macOs.

Brice Dutheil has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo
  
  Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/10/files
  - new: https://git.openjdk.java.net/jextract/pull/10/files/baf128b7..cee993b8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=10&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=10&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jextract/pull/10.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/10/head:pull/10

PR: https://git.openjdk.java.net/jextract/pull/10

From duke at openjdk.java.net  Tue Mar 29 13:15:47 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Tue, 29 Mar 2022 13:15:47 GMT
Subject: RFR: Update Readme with macOs specifics [v3]
In-Reply-To: <xQM183QoYbM0EBwiIAQZgpji8leRdCu-JAtstXRwtDg=.cfdedbc4-e9dd-4bb4-905f-41f645b89848@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <YUVQlcKBPiCpaOc02ihJXyAePnv5uS4gKB6yMUWlDrQ=.007b998b-192d-472a-8ccb-06c89a1cc797@github.com>
 <xQM183QoYbM0EBwiIAQZgpji8leRdCu-JAtstXRwtDg=.cfdedbc4-e9dd-4bb4-905f-41f645b89848@github.com>
Message-ID: <KIKq3RCwRiCwy9qGk1ZcsLeoOXKPvYnt7pEQMExvnx4=.d009268c-af91-4653-995b-377ce130fa98@github.com>

On Tue, 29 Mar 2022 12:59:44 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Brice Dutheil has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make local installation quoted
>
> README.md line 18:
> 
>> 16: > <details><summary><strong>Using a local installation of LLVM</strong></summary>
>> 17: > 
>> 18: > While the recommanded way is to use a [release from the LLVM project](https://releases.llvm.org/download.html),
> 
> Small typo here
> Suggestion:
> 
>> While the recommended way is to use a [release from the LLVM project](https://releases.llvm.org/download.html),

Ah thank you ??

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

PR: https://git.openjdk.java.net/jextract/pull/10

From duke at openjdk.java.net  Tue Mar 29 13:37:04 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Tue, 29 Mar 2022 13:37:04 GMT
Subject: RFR: Update Readme with macOs specifics [v2]
In-Reply-To: <LUCmeEwMesieK2VD-klyKT-dGIONN-PRu4fYCKIHTkQ=.9e7299d1-f437-449d-8cab-bfa27593a51e@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <q_e0XBRLTGKS0xu44pDPBckk8gpY2Mp_DGmAC565ahQ=.55fded51-e6b7-42a5-862b-afc2c9ec1800@github.com>
 <mwFPCWRfxi919_SnPGWBHREpZNkrgfbZWZ89_2ysv5A=.0b78d292-523a-4d6f-be5c-b20ab7059535@github.com>
 <pKvGvUys-IOxqpgMEjJQWwYT0Qa3m2A1iu8_zOQNNkA=.f9e9790d-0a4f-41d3-b307-0c6b9574c258@github.com>
 <LUCmeEwMesieK2VD-klyKT-dGIONN-PRu4fYCKIHTkQ=.9e7299d1-f437-449d-8cab-bfa27593a51e@github.com>
Message-ID: <WhEF3W8biwSMohF6FytLPgt6tMuKTIibjFnXuekJY-Q=.68ca09bc-9159-4cf1-8556-da4a889f0971@github.com>

On Tue, 29 Mar 2022 11:20:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> What we might want to do is to add a post jpackage step which renames the folder to something consistent across platforms.

At this time I don't think it's possible to do that with the output of jpackage, on macOs `jextract` binary will lookup for its config file at `../../Contents/app/jextract.cfg`, then `../../Contents/runtime`, etc.



$ tree build/jextract.app
build/jextract.app
??? Contents
    ??? Info.plist
    ??? MacOS
    ??? ??? jextract
    ??? PkgInfo
    ??? Resources
    ??? ??? jextract.icns
    ??? app
    ??? ??? jextract.cfg
    ??? runtime
        ??? Contents
            ??? Home
            ??? ??? bin
            ??? ??? ??? java
            ??? ??? ??? javac
            ??? ??? ??? keytool
            ??? ??? ??? serialver
            ??? ??? conf
            ??? ??? ??? jextract
            ??? ??? ??? ??? __clang_cuda_builtin_vars.h
            ??? ??? ??? ??? __clang_cuda_cmath.h
            ??? ??? ??? ??? ...
            ??? ??? ??? net.properties
            ??? ??? ??? security
            ??? ???     ??? java.policy
            ??? ???     ??? java.security
            ??? ???     ??? policy
            ??? ???         ??? ...
            ??? ??? include
            ??? ??? ??? classfile_constants.h
            ??? ??? ??? darwin
            ??? ??? ??? ??? jni_md.h
            ??? ??? ??? jni.h
            ??? ??? ??? jvmti.h
            ??? ??? ??? jvmticmlr.h
            ??? ??? legal
            ??? ??? ??? ...
            ??? ??? ??? jdk.incubator.foreign
            ??? ???     ??? ADDITIONAL_LICENSE_INFO
            ??? ???     ??? ASSEMBLY_EXCEPTION
            ??? ???     ??? LICENSE
            ??? ??? lib
            ??? ??? ??? classlist
            ??? ??? ??? ct.sym
            ??? ??? ??? jrt-fs.jar
            ??? ??? ??? jspawnhelper
            ??? ??? ??? jvm.cfg
            ??? ??? ??? libLLVM.dylib
            ??? ??? ??? libclang.dylib
            ??? ??? ??? libjava.dylib
            ??? ??? ??? libjimage.dylib
            ??? ??? ??? libjli.dylib
            ??? ??? ??? libjsig.dylib
            ??? ??? ??? libnet.dylib
            ??? ??? ??? libnio.dylib
            ??? ??? ??? libosxsecurity.dylib
            ??? ??? ??? libprefs.dylib
            ??? ??? ??? libsyslookup.dylib
            ??? ??? ??? libverify.dylib
            ??? ??? ??? libzip.dylib
            ??? ??? ??? modules
            ??? ??? ??? security
            ??? ??? ??? ??? blocked.certs
            ??? ??? ??? ??? cacerts
            ??? ??? ??? ??? default.policy
            ??? ??? ??? ??? public_suffix_list.dat
            ??? ??? ??? server
            ??? ??? ??? ??? libjsig.dylib
            ??? ??? ??? ??? libjvm.dylib
            ??? ??? ??? tzdb.dat
            ??? ??? release
            ??? Info.plist
            ??? MacOS
                ??? libjli.dylib

27 directories, 233 files

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

PR: https://git.openjdk.java.net/jextract/pull/10

From duke at openjdk.java.net  Tue Mar 29 13:45:05 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Tue, 29 Mar 2022 13:45:05 GMT
Subject: RFR: 7903136: Don't require jdk18_home to be set in jextract
 gradle build
In-Reply-To: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
References: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
Message-ID: <Cwcx-KeSVg9PqjYONh67_PdZQbx8hPW-I9uhmb0nY_I=.d3f0da92-3b6c-4f0e-9aac-84bac83fa78e@github.com>

On Mon, 28 Mar 2022 16:02:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Drop the requirement to set `jdk18_home` in the gradle build, and rely instead on `JAVA_HOME` being set to JDK 18.
> 
> I've also updated the build instructions. The `-Pjtreg_home` flag seems to have been dropped by accident from the test command. I've re-added it. Also renamed `libclang_dir` -> `llvm_dir` which was missed in an earlier change.

Fair. I believe tool-chains support will improve in the future. IntelliJ for example don't explicitly support tool-chain but it will follow what is declared in Gradle, so this might be encoded as Gradle task which is indeed inefficient in some cases.
Maybe this can be revisited when tool-chains tooling is more solid and more compelling.

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

PR: https://git.openjdk.java.net/jextract/pull/9

From jvernee at openjdk.java.net  Tue Mar 29 18:18:42 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 29 Mar 2022 18:18:42 GMT
Subject: RFR: 7903136: Don't require jdk18_home to be set in jextract
 gradle build [v2]
In-Reply-To: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
References: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
Message-ID: <O1PWXhFCUsyxT1vEGBkmRkDigvbPdqdMPH4l6-6vCEc=.d6d2ab58-7426-428f-b1f2-02023a4c7a01@github.com>

> Drop the requirement to set `jdk18_home` in the gradle build, and rely instead on `JAVA_HOME` being set to JDK 18.
> 
> I've also updated the build instructions. The `-Pjtreg_home` flag seems to have been dropped by accident from the test command. I've re-added it. Also renamed `libclang_dir` -> `llvm_dir` which was missed in an earlier change.

Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:

 - Add automatic JDK download
 - Have -Pjdk flag to specify jdk manually, and allow jdks with higher version as well

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/9/files
  - new: https://git.openjdk.java.net/jextract/pull/9/files/1b4682d9..d6434bd7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=9&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=9&range=00-01

  Stats: 79 lines in 3 files changed: 62 ins; 5 del; 12 mod
  Patch: https://git.openjdk.java.net/jextract/pull/9.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/9/head:pull/9

PR: https://git.openjdk.java.net/jextract/pull/9

From jvernee at openjdk.java.net  Tue Mar 29 18:25:33 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 29 Mar 2022 18:25:33 GMT
Subject: RFR: 7903136: Don't require jdk18_home to be set in jextract
 gradle build [v3]
In-Reply-To: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
References: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
Message-ID: <VToopSfnEQ_vrUN8v0TFhMlJ_8JkF8MsuVqm_SqWlzQ=.db274aba-422d-4ad5-bd25-7f14dd0984d7@github.com>

> Drop the requirement to set `jdk18_home` in the gradle build, and rely instead on `JAVA_HOME` being set to JDK 18.
> 
> I've also updated the build instructions. The `-Pjtreg_home` flag seems to have been dropped by accident from the test command. I've re-added it. Also renamed `libclang_dir` -> `llvm_dir` which was missed in an earlier change.

Jorn Vernee has updated the pull request incrementally with three additional commits since the last revision:

 - Phrasing 2
 - Phrasing
 - Drop java.home fallback + update readme

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/9/files
  - new: https://git.openjdk.java.net/jextract/pull/9/files/d6434bd7..9563246c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=9&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=9&range=01-02

  Stats: 9 lines in 2 files changed: 0 ins; 7 del; 2 mod
  Patch: https://git.openjdk.java.net/jextract/pull/9.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/9/head:pull/9

PR: https://git.openjdk.java.net/jextract/pull/9

From jvernee at openjdk.java.net  Tue Mar 29 18:25:34 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 29 Mar 2022 18:25:34 GMT
Subject: RFR: 7903136: Don't require jdk18_home to be set in jextract
 gradle build [v2]
In-Reply-To: <O1PWXhFCUsyxT1vEGBkmRkDigvbPdqdMPH4l6-6vCEc=.d6d2ab58-7426-428f-b1f2-02023a4c7a01@github.com>
References: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
 <O1PWXhFCUsyxT1vEGBkmRkDigvbPdqdMPH4l6-6vCEc=.d6d2ab58-7426-428f-b1f2-02023a4c7a01@github.com>
Message-ID: <FvpMN4yOu-zbdNSQYH8MVmzLvvobquGYMaSQrdAcr18=.2af35667-57c5-4f49-bbd8-825c3e5cf45f@github.com>

On Tue, 29 Mar 2022 18:18:42 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Drop the requirement to set `jdk18_home` in the gradle build, and rely instead on `JAVA_HOME` being set to JDK 18.
>> 
>> I've also updated the build instructions. The `-Pjtreg_home` flag seems to have been dropped by accident from the test command. I've re-added it. Also renamed `libclang_dir` -> `llvm_dir` which was missed in an earlier change.
>
> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add automatic JDK download
>  - Have -Pjdk flag to specify jdk manually, and allow jdks with higher version as well

I've updated the PR and added an automatic download step that downloads JDK 18 from jdk.java.net when `-Pjdk` is not specified.

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

PR: https://git.openjdk.java.net/jextract/pull/9

From jvernee at openjdk.java.net  Tue Mar 29 18:29:55 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 29 Mar 2022 18:29:55 GMT
Subject: RFR: 7903136: Don't require jdk18_home to be set in jextract
 gradle build [v4]
In-Reply-To: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
References: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
Message-ID: <YSwLuq2Uo1gOFismYyOORabrxn8UFnm7rFmnOYZNda0=.922b7260-b3ed-44df-88c6-108b4d2d418d@github.com>

> Drop the requirement to set `jdk18_home` in the gradle build, and rely instead on `JAVA_HOME` being set to JDK 18.
> 
> I've also updated the build instructions. The `-Pjtreg_home` flag seems to have been dropped by accident from the test command. I've re-added it. Also renamed `libclang_dir` -> `llvm_dir` which was missed in an earlier change.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Tabs to spaces

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

Changes:
  - all: https://git.openjdk.java.net/jextract/pull/9/files
  - new: https://git.openjdk.java.net/jextract/pull/9/files/9563246c..1de0973f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jextract&pr=9&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jextract&pr=9&range=02-03

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jextract/pull/9.diff
  Fetch: git fetch https://git.openjdk.java.net/jextract pull/9/head:pull/9

PR: https://git.openjdk.java.net/jextract/pull/9

From sundar at openjdk.java.net  Wed Mar 30 09:22:56 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Wed, 30 Mar 2022 09:22:56 GMT
Subject: RFR: 7903136: Don't require jdk18_home to be set in jextract
 gradle build [v4]
In-Reply-To: <YSwLuq2Uo1gOFismYyOORabrxn8UFnm7rFmnOYZNda0=.922b7260-b3ed-44df-88c6-108b4d2d418d@github.com>
References: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
 <YSwLuq2Uo1gOFismYyOORabrxn8UFnm7rFmnOYZNda0=.922b7260-b3ed-44df-88c6-108b4d2d418d@github.com>
Message-ID: <xK0NI1bMXAA64I8jyfWrkXvqRYa9T0l4ioisk-cYixM=.b1f429cc-a0ef-435f-b02b-6f12e0fa3a9b@github.com>

On Tue, 29 Mar 2022 18:29:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Drop the requirement to set `jdk18_home` in the gradle build, and rely instead on `JAVA_HOME` being set to JDK 18.
>> 
>> I've also updated the build instructions. The `-Pjtreg_home` flag seems to have been dropped by accident from the test command. I've re-added it. Also renamed `libclang_dir` -> `llvm_dir` which was missed in an earlier change.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tabs to spaces

README.md line 10:

> 8: 
> 9: The JDK used to build jextract can be specified with `-Pjdk=/path/to/jdk`. If that option is omitted, a build JDK will be downloaded automatically.
> 10: 

Should we say JDK used to build jextract should be jdk 18 ?

build.gradle line 93:

> 91:     println("using JDK from 'jdk' project property");
> 92:     jdkHome = project.property("jdk");
> 93:     checkJDKRelease(jdkHome, minimalJDKVersion);

we check minimum JDK. So.. jdk 19 will be accepted even after foreign-preview hits jdk 19. But that won't work with this version of jdk. I think it is better to accept only jdk 18 - as this jextract code/test/samples work only with jdk 18.

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

PR: https://git.openjdk.java.net/jextract/pull/9

From jvernee at openjdk.java.net  Wed Mar 30 10:47:57 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 30 Mar 2022 10:47:57 GMT
Subject: RFR: 7903136: Don't require jdk18_home to be set in jextract
 gradle build [v4]
In-Reply-To: <xK0NI1bMXAA64I8jyfWrkXvqRYa9T0l4ioisk-cYixM=.b1f429cc-a0ef-435f-b02b-6f12e0fa3a9b@github.com>
References: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
 <YSwLuq2Uo1gOFismYyOORabrxn8UFnm7rFmnOYZNda0=.922b7260-b3ed-44df-88c6-108b4d2d418d@github.com>
 <xK0NI1bMXAA64I8jyfWrkXvqRYa9T0l4ioisk-cYixM=.b1f429cc-a0ef-435f-b02b-6f12e0fa3a9b@github.com>
Message-ID: <F1ZBdwKPjXFB_yW7YcLbm38ncGAOHn-Ep-AYCZOTvFg=.c708e460-f582-402a-bf9a-0fa84c6e6c38@github.com>

On Wed, 30 Mar 2022 09:17:11 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tabs to spaces
>
> README.md line 10:
> 
>> 8: 
>> 9: The JDK used to build jextract can be specified with `-Pjdk=/path/to/jdk`. If that option is omitted, a build JDK will be downloaded automatically.
>> 10: 
> 
> Should we say JDK used to build jextract should be jdk 18 ?

The jdk 18 requirement is listed in the paragraph before.

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

PR: https://git.openjdk.java.net/jextract/pull/9

From jvernee at openjdk.java.net  Wed Mar 30 10:54:05 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 30 Mar 2022 10:54:05 GMT
Subject: RFR: 7903136: Don't require jdk18_home to be set in jextract
 gradle build [v4]
In-Reply-To: <YSwLuq2Uo1gOFismYyOORabrxn8UFnm7rFmnOYZNda0=.922b7260-b3ed-44df-88c6-108b4d2d418d@github.com>
References: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
 <YSwLuq2Uo1gOFismYyOORabrxn8UFnm7rFmnOYZNda0=.922b7260-b3ed-44df-88c6-108b4d2d418d@github.com>
Message-ID: <e0huqJNuojqsii70rchCtl1vn55AUzNHzBgLOZAXuD0=.195967bd-ac1c-4bb7-a92b-04e9ffd791b0@github.com>

On Tue, 29 Mar 2022 18:29:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Drop the requirement to set `jdk18_home` in the gradle build, and rely instead on `JAVA_HOME` being set to JDK 18.
>> 
>> I've also updated the build instructions. The `-Pjtreg_home` flag seems to have been dropped by accident from the test command. I've re-added it. Also renamed `libclang_dir` -> `llvm_dir` which was missed in an earlier change.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tabs to spaces

After some consideration and offline discussion. Implementing & maintaining our own JDK download code doesn't seem like it gives enough benefit for the cost.

For now we will stick with users manually having to supply a JDK 18 home. A local `gradle.properties` file could also be used to avoid having to pass this flag every time when invoking gradle. As well as using gradle with IntelliJ, which doesn't support passing command line flags to it's gradle builder (AFAICT).

Maybe once the toolchain feature supports jdk.java.net JDKs out-of-the-box, we could reconsider.

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

PR: https://git.openjdk.java.net/jextract/pull/9

From jvernee at openjdk.java.net  Wed Mar 30 10:54:07 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 30 Mar 2022 10:54:07 GMT
Subject: Withdrawn: 7903136: Don't require jdk18_home to be set in jextract
 gradle build
In-Reply-To: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
References: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
Message-ID: <_aD6TfkHHWvixYnmGn4D_h3xb_aEnJdpu1hZBxd3b6A=.44dd2ef0-59e9-4c3a-9000-d840d8b13f4f@github.com>

On Mon, 28 Mar 2022 16:02:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Drop the requirement to set `jdk18_home` in the gradle build, and rely instead on `JAVA_HOME` being set to JDK 18.
> 
> I've also updated the build instructions. The `-Pjtreg_home` flag seems to have been dropped by accident from the test command. I've re-added it. Also renamed `libclang_dir` -> `llvm_dir` which was missed in an earlier change.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jextract/pull/9

From duke at openjdk.java.net  Wed Mar 30 11:12:05 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Wed, 30 Mar 2022 11:12:05 GMT
Subject: RFR: 7903136: Don't require jdk18_home to be set in jextract
 gradle build [v4]
In-Reply-To: <YSwLuq2Uo1gOFismYyOORabrxn8UFnm7rFmnOYZNda0=.922b7260-b3ed-44df-88c6-108b4d2d418d@github.com>
References: <yBlghkLBQQHk83ZayUiVkz9GvIN4l4vH0IjO0alWTpI=.256af1ca-6657-44e3-a2f9-20499120bf35@github.com>
 <YSwLuq2Uo1gOFismYyOORabrxn8UFnm7rFmnOYZNda0=.922b7260-b3ed-44df-88c6-108b4d2d418d@github.com>
Message-ID: <YsP0W4o9kRW29JfmBdlNCQ4BptKpuvDuz_S3A7Rkk0k=.b2c259af-dc79-4be5-8e6d-0a891f39d692@github.com>

On Tue, 29 Mar 2022 18:29:55 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Drop the requirement to set `jdk18_home` in the gradle build, and rely instead on `JAVA_HOME` being set to JDK 18.
>> 
>> I've also updated the build instructions. The `-Pjtreg_home` flag seems to have been dropped by accident from the test command. I've re-added it. Also renamed `libclang_dir` -> `llvm_dir` which was missed in an earlier change.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tabs to spaces

build.gradle line 39:

> 37:     }
> 38: 
> 39:     String foundVersionStr = props.getProperty("JAVA_VERSION");

Just for information: In my experience checking the version in the release file is unfortunately not enough to ascertain a valid JDK. In particular when playing with multiple variant / builds. This might be a remote problem, but I think getting system properties is better.

So executing something like (pseudo code)


def file = Files.createTempFile("sysprop", ".java").toFile()
file.deleteOnExit()

def proc = new ProcessBuilder(['java', '--source', '11', file.absolutePath]).start()

proc.waitFor()

if (0 != proc.exitValue()) {
    throw new RuntimeException("can't read system properties: ${proc.exitValue()}")
}


Properties props = new Properties();
try (InputStream input = proc.inputStream) {
    props.load(input);
}


The command could be replaced by: `jshell -s - <<< "System.getProperties().forEach((k, v) -> System.out.println(k + "=" + v))"` thus avoiding the temporary file.

build.gradle line 59:

> 57: 
> 58: def String downloadJDK() {
> 59:     String jdkUrl = "https://download.java.net/java/GA/jdk18/43f95e8614114aeaa8e8a5fcf20a682d/36/GPL/openjdk-18_";

You should put this in a property so gradle won't have to recompile/reconfigure the script if this value changes.

build.gradle line 92:

> 90: if (project.hasProperty("jdk")) {
> 91:     println("using JDK from 'jdk' project property");
> 92:     jdkHome = project.property("jdk");

I think the property assignment can be replaced by the following, if the property is not found then it will return `null`

Suggestion:

String jdkHome = project.findProperty("jdk");
if (jdkHome != null) {
    logger.lifecycle("using JDK from 'jdk' project property");


Also you may want to replace `println` by logger statements, although that may be a bit out of scope to do that for the whole file in this PR.

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

PR: https://git.openjdk.java.net/jextract/pull/9

From duke at openjdk.java.net  Wed Mar 30 11:16:01 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Wed, 30 Mar 2022 11:16:01 GMT
Subject: RFR: Update Readme with macOs specifics
In-Reply-To: <SQ6rlaidCY29WgfR3hud8bV0YurqsTHmrukvrDznkP0=.12387b20-30a8-4e4e-908a-88c2ebe79bd8@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <SQ6rlaidCY29WgfR3hud8bV0YurqsTHmrukvrDznkP0=.12387b20-30a8-4e4e-908a-88c2ebe79bd8@github.com>
Message-ID: <tuU3qv4cyqmilwBZi3PDXmCrwwgb9h7LBl3TWfDjErQ=.19c47f5c-cfa2-4472-af9f-45013d9d0ce3@github.com>

On Mon, 28 Mar 2022 17:32:43 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> The macOs libclang location as well as build output differ enough to warrant specific information. In particular the use of the XCode based path to find the libclang is not an easy find. The output also makes use of jpackage with `app-image` type, but the macOs _.app_ layout different enough on macOs.
>
> I'm also feeling a little split here. Providing many different instructions for different setups seems more likely to leave the documentation for some of them going out of date (this has been my experience with other projects). I think I'd prefer having 1 recommended way of installing LLVM, which is the LLVM release page, which we can also guarantee works.
> 
> For now though, I don't mind listing the alternatives. But I'd suggest hiding them in a spoiler block (using `<details><summary>LLVM location for alternative packages</summary>...</details>`). And I think we should spell out the recommended way to get the package (download, unzip/untar, point `libclang_dir` to extracted folder) a bit more front and center as well.

@JornVernee @mcimadamore If you're ok with the changes how should we proceed with this PR. I believe it needs sponsoring beforehand.

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

PR: https://git.openjdk.java.net/jextract/pull/10

From jvernee at openjdk.java.net  Wed Mar 30 11:16:03 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 30 Mar 2022 11:16:03 GMT
Subject: RFR: Update Readme with macOs specifics [v4]
In-Reply-To: <LjL7M6tHWxeoUKU9v6Y7dlkuRYLq0qJISHM-pp8GkHg=.b9ac2346-d5cc-4ba2-a0ed-ee75a96b2730@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <LjL7M6tHWxeoUKU9v6Y7dlkuRYLq0qJISHM-pp8GkHg=.b9ac2346-d5cc-4ba2-a0ed-ee75a96b2730@github.com>
Message-ID: <dQMzI4OY0vCq8SP62PpCd9FDgTF_zo81AGoCitAPKCE=.075e6807-cd73-482f-852d-b57d09abc33b@github.com>

On Tue, 29 Mar 2022 13:15:46 GMT, Brice Dutheil <duke at openjdk.java.net> wrote:

>> The macOs libclang location as well as build output differ enough to warrant specific information. In particular the use of the XCode based path to find the libclang is not an easy find. The output also makes use of jpackage with `app-image` type, but the macOs _.app_ layout different enough on macOs.
>
> Brice Dutheil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo
>   
>   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

Once you issue `/integrate` the bot will add the `sponsor` label, and then Maurizio can issue `/sponsor` to integrate it.

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

PR: https://git.openjdk.java.net/jextract/pull/10

From mcimadamore at openjdk.java.net  Wed Mar 30 11:42:59 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 30 Mar 2022 11:42:59 GMT
Subject: RFR: Update Readme with macOs specifics [v4]
In-Reply-To: <LjL7M6tHWxeoUKU9v6Y7dlkuRYLq0qJISHM-pp8GkHg=.b9ac2346-d5cc-4ba2-a0ed-ee75a96b2730@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <LjL7M6tHWxeoUKU9v6Y7dlkuRYLq0qJISHM-pp8GkHg=.b9ac2346-d5cc-4ba2-a0ed-ee75a96b2730@github.com>
Message-ID: <Yjj19Z2stkplc6U3IUooC-ncvlAyfz5a-210lRlah_8=.101b7e6e-d6e9-444b-abe5-71a34653cf29@github.com>

On Tue, 29 Mar 2022 13:15:46 GMT, Brice Dutheil <duke at openjdk.java.net> wrote:

>> The macOs libclang location as well as build output differ enough to warrant specific information. In particular the use of the XCode based path to find the libclang is not an easy find. The output also makes use of jpackage with `app-image` type, but the macOs _.app_ layout different enough on macOs.
>
> Brice Dutheil has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo
>   
>   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

Looks good

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

Marked as reviewed by mcimadamore (Committer).

PR: https://git.openjdk.java.net/jextract/pull/10

From duke at openjdk.java.net  Wed Mar 30 14:01:51 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Wed, 30 Mar 2022 14:01:51 GMT
Subject: RFR: Update Readme with macOs specifics
In-Reply-To: <QtRTj8MzhFcPCLgMAAVzFVsii0dDvLEaVdJTSpNUSDk=.6b8bf840-836b-4d0e-a6d9-02ec284aa0e0@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
 <rwQ-2LkCxq6FH0lfX7wxaqg7Y79UAdSh6zLP_ArDeDU=.6e4bad2b-f878-40ef-a321-c9a8d0d54c8b@github.com>
 <QtRTj8MzhFcPCLgMAAVzFVsii0dDvLEaVdJTSpNUSDk=.6b8bf840-836b-4d0e-a6d9-02ec284aa0e0@github.com>
Message-ID: <yShaJgIX03Sm77PUPNyv4Y2gtAGUilApy6V0Kpu_lkA=.f60d3965-2153-4f8a-964d-111ace4914fb@github.com>

On Mon, 28 Mar 2022 20:25:46 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I felt the same and wondered if a different file was needed, but the details block looks good for me.
>> 
>> Regarding Linux (or else) I felt this was an opportunity to document these LLVM installs as well. And may improve usability.
>> 
>> After reading your comment I think that if the build should prefer an actual download of LLVM it might be better to write a gradle task that performs the download and extraction. It should be quite ready and it might improve the deterministic aspect as the build.
>
>> After reading your comment I think that if the build should prefer an actual download of LLVM it might be better to write a gradle task that performs the download and extraction. It should be quite ready and it might improve the deterministic aspect as the build.
> 
> This is something we are considering, for both the JDK and libclang.

Thank you @mcimadamore @JornVernee

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

PR: https://git.openjdk.java.net/jextract/pull/10

From duke at openjdk.java.net  Wed Mar 30 14:01:52 2022
From: duke at openjdk.java.net (Brice Dutheil)
Date: Wed, 30 Mar 2022 14:01:52 GMT
Subject: Integrated: Update Readme with macOs specifics
In-Reply-To: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
References: <m8bQznt8vscH-me8wU8D3s59W8i-DfcqOVPHiIdfD24=.5b9e0896-df98-4f1b-9573-b96b14e9628f@github.com>
Message-ID: <adp07msGjJCVh9NO2vju3AJONuQXHcZPKYHt3h1V5NA=.c007c5c5-7777-46f6-bca6-8fa06e9f770c@github.com>

On Mon, 28 Mar 2022 16:32:42 GMT, Brice Dutheil <duke at openjdk.java.net> wrote:

> The macOs libclang location as well as build output differ enough to warrant specific information. In particular the use of the XCode based path to find the libclang is not an easy find. The output also makes use of jpackage with `app-image` type, but the macOs _.app_ layout different enough on macOs.

This pull request has now been integrated.

Changeset: 07d81c73
Author:    Brice Dutheil <brice.dutheil at gmail.com>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jextract/commit/07d81c73208d53319920f7ffd1fa90d0b04de466
Stats:     19 lines in 1 file changed: 16 ins; 0 del; 3 mod

Update Readme with macOs specifics

Reviewed-by: jvernee, mcimadamore

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

PR: https://git.openjdk.java.net/jextract/pull/10

From maurizio.cimadamore at oracle.com  Thu Mar 31 13:51:15 2022
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 31 Mar 2022 14:51:15 +0100
Subject: test email - please ignore
Message-ID: <1cbd92b1-e0c3-dbd3-d29b-d77dcbd23bf7@oracle.com>

Please ignore

Maurizio