From duke at openjdk.org  Sun Feb  2 14:12:57 2025
From: duke at openjdk.org (Emrul)
Date: Sun, 2 Feb 2025 14:12:57 GMT
Subject: RFR: 7903731: Jextract should support macOS frameworks [v3]
In-Reply-To: <5lkdlfTAzs5AEbVyiw2T2TCVMNf02WuTmTULyh738Vk=.d2553ec3-ab12-47ab-ab98-2c6bf7a3aeef@github.com>
References: <eN2zSInMQq2Mq3jZQMLQMJ932pmJH4ZDzBxrr6Hksgg=.a1c51c51-aaca-4dcd-9c4e-4f419b44e301@github.com>
 <5lkdlfTAzs5AEbVyiw2T2TCVMNf02WuTmTULyh738Vk=.d2553ec3-ab12-47ab-ab98-2c6bf7a3aeef@github.com>
Message-ID: <r2FETectsW2KaZApw1wyj7gqCStpx_Ug9P_jvesraKM=.7291479c-5b27-4019-b8bb-39ea8d5f4b3b@github.com>

On Thu, 2 Jan 2025 19:14:26 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Read the JBS issue for more detail.
>> 
>> This patch adds two new mac specific options, to make it easier to use frameworks and remove the need of a `compile_flags.txt` file. An exception is thrown if those options are used from an other platform, the error message is inspired from `jpackage`
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use consistent spacing

I'm interested in this PR and I gave it a quick test to see if I could import bits of the WebKit Framework. Unless I'm doing something wrong (which is quite possible as its the first time I'm attempting to use jextract...) it appears not to work as expected. 
For example:

./jextract --output ./tmp   --target-package com.example.webview.webkit -f Foundation -f WebKit /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/WebKit.framework/Headers/NSAttributedString.h


Returns some errors such as:

NSObjCRuntime.h:609:19: error: unknown type name 'NSString'
NSObjCRuntime.h:610:53: error: unknown type name 'NSString'
NSObjCRuntime.h:612:19: error: unknown type name 'NSString'
NSObjCRuntime.h:612:50: error: unknown type name 'Protocol'
NSObjCRuntime.h:613:19: error: unknown type name 'Protocol'

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

PR Comment: https://git.openjdk.org/jextract/pull/268#issuecomment-2629407732

From nbenalla at openjdk.org  Mon Feb  3 18:57:04 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 3 Feb 2025 18:57:04 GMT
Subject: RFR: 7903731: Jextract should support macOS frameworks [v3]
In-Reply-To: <5lkdlfTAzs5AEbVyiw2T2TCVMNf02WuTmTULyh738Vk=.d2553ec3-ab12-47ab-ab98-2c6bf7a3aeef@github.com>
References: <eN2zSInMQq2Mq3jZQMLQMJ932pmJH4ZDzBxrr6Hksgg=.a1c51c51-aaca-4dcd-9c4e-4f419b44e301@github.com>
 <5lkdlfTAzs5AEbVyiw2T2TCVMNf02WuTmTULyh738Vk=.d2553ec3-ab12-47ab-ab98-2c6bf7a3aeef@github.com>
Message-ID: <s1lnVLM7TCzQqQiKZ6eCo6Q1fq1qbqrIYP_cXyH8mYw=.e099a180-17cb-4c6c-a146-0daf706e7e4f@github.com>

On Thu, 2 Jan 2025 19:14:26 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Read the JBS issue for more detail.
>> 
>> This patch adds two new mac specific options, to make it easier to use frameworks and remove the need of a `compile_flags.txt` file. An exception is thrown if those options are used from an other platform, the error message is inspired from `jpackage`
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use consistent spacing

This PR will only make dealing with MacOs frameworks easier, but if you couldn't generate the Java bindings before this change, you still won't be able to afterward.

jextract will explicitly throw errors for things that are not in the C language (see `TreeMaker::createTree`), I don't think it can process objective-c only constructs out of the box so you will need to make some changes.

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

PR Comment: https://git.openjdk.org/jextract/pull/268#issuecomment-2631804944

From nbenalla at openjdk.org  Mon Feb  3 19:00:40 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 3 Feb 2025 19:00:40 GMT
Subject: RFR: 7903933: Move sharable items from different generations to a
 common file
Message-ID: <wh96s-H47MfSjS8FPoOdrkoU5jomlt8tpxXhADC-sNI=.0602f392-947a-49db-bd8b-dc68ed6a0f91@github.com>

Please review this patch to move the `C_*` layouts and the static utility methods into separate classes: `LayoutUtils.java` and `FFMUtils.java`, respectively.

- The names could later be personalized through a JSON configuration.
- We can use static imports if the `-t` option is no used and the files are generated into the default package, in that case we use the classname to call the static methods or use the `C_*` constants.

Some tests had to be modified slightly, either by adding new static imports or replacing classnames.

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

Commit messages:
 - move sharable items to a common class

Changes: https://git.openjdk.org/jextract/pull/278/files
  Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=278&range=00
  Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903933
  Stats: 411 lines in 21 files changed: 233 ins; 106 del; 72 mod
  Patch: https://git.openjdk.org/jextract/pull/278.diff
  Fetch: git fetch https://git.openjdk.org/jextract.git pull/278/head:pull/278

PR: https://git.openjdk.org/jextract/pull/278

From nbenalla at openjdk.org  Tue Feb  4 13:07:42 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 4 Feb 2025 13:07:42 GMT
Subject: RFR: 7903933: Move sharable items from different generations to a
 common file [v2]
In-Reply-To: <wh96s-H47MfSjS8FPoOdrkoU5jomlt8tpxXhADC-sNI=.0602f392-947a-49db-bd8b-dc68ed6a0f91@github.com>
References: <wh96s-H47MfSjS8FPoOdrkoU5jomlt8tpxXhADC-sNI=.0602f392-947a-49db-bd8b-dc68ed6a0f91@github.com>
Message-ID: <RDazWGWjQeRNHrfnOXLcCKMTXrxyxmef1K-AqVc-2kI=.82914bcd-be98-4f13-8825-37b84453811c@github.com>

> Please review this patch to move the `C_*` layouts and the static utility methods into separate classes: `LayoutUtils.java` and `FFMUtils.java`, respectively.
> 
> - The names could later be personalized through a JSON configuration.
> - We can use static imports if the `-t` option is no used and the files are generated into the default package, in that case we use the classname to call the static methods or use the `C_*` constants.
> 
> Some tests had to be modified slightly, either by adding new static imports or replacing classnames.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  replace hardcoded strings I missed

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

Changes:
  - all: https://git.openjdk.org/jextract/pull/278/files
  - new: https://git.openjdk.org/jextract/pull/278/files/583bcf61..fa41fe8b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jextract&pr=278&range=01
 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=278&range=00-01

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

PR: https://git.openjdk.org/jextract/pull/278

From nilskemail at gmail.com  Thu Feb 13 16:51:09 2025
From: nilskemail at gmail.com (Nils Kattenbeck)
Date: Thu, 13 Feb 2025 17:51:09 +0100
Subject: jextract fails to work on sd-daemon.h due to wrong handling of
 __INCLUDE_LEVEL__
Message-ID: <CAKkJDRdNikfAhR8pkontZU6XaFi0na4jKPxS7Q_fHkp7FKCFuQ@mail.gmail.com>

Dear all,

Today I tried to use jextract on sd-daemon.h (from systemd) to access the
sd_notify* class of functions. To my surprise this did not work and
returned in the following error message:

../jextract-21/bin/jextract --source -t foo.bar
/usr/include/systemd/sd-daemon.h
WARNING: A restricted method in java.lang.foreign.AddressLayout has been
called
WARNING: java.lang.foreign.AddressLayout::withTargetLayout has been called
by module org.openjdk.jextract
WARNING: Use --enable-native-access=org.openjdk.jextract to avoid a warning
for this module

/usr/include/systemd/_sd-common.h:23:4: error: "Do not include _sd-common.h
directly; it is a private header."

which comes down to the following preprocessor code in _sd-common.h (which
is included by sd-daemon.h):

#if defined(__INCLUDE_LEVEL__) && __INCLUDE_LEVEL__ <= 1 &&
!defined(__COVERITY__)
#  error "Do not include _sd-common.h directly; it is a private header."
#endif

It seems like jextract does not increase the __INCLUDE_LEVEL__ resulting in
this error. However, it does seem to define it which makes this more
curious.
The fix would be to either a) not set it at all or b) correctly increment
it when parsing files from an  #include statement.

For now I have been able to circumvent this by telling jextract to also
define __COVERITY__ though this is only a very dirty hack and will not work
in every instance.

Cheers,
Nils
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250213/7a05cf52/attachment.htm>

From jorn.vernee at oracle.com  Fri Feb 14 22:46:29 2025
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Fri, 14 Feb 2025 23:46:29 +0100
Subject: jextract fails to work on sd-daemon.h due to wrong handling of
 __INCLUDE_LEVEL__
In-Reply-To: <CAKkJDRdNikfAhR8pkontZU6XaFi0na4jKPxS7Q_fHkp7FKCFuQ@mail.gmail.com>
References: <CAKkJDRdNikfAhR8pkontZU6XaFi0na4jKPxS7Q_fHkp7FKCFuQ@mail.gmail.com>
Message-ID: <9fd8145b-6eaa-4243-897a-7449f414b619@oracle.com>

Hey Nils,

Jextract uses clang under the hood to do the parsing, so it is clang 
that is managing the __INCLUDE_LEVEL__ value, and I'm assuming it does 
that correctly.

I think the issue here is that, normally, you would write a program that 
includes sd-daemon.h, so the include level of that file starts out at 1, 
with the main program translation unit being level 0. But, since 
jextract uses clang to parse the sd-daemon.h file directly, it has 
include level 0 instead, and this implementation header seems to end up 
with include level 1, failing the check. You should see the same error 
if you directly pass sd-daemon.h to clang (or gcc).

I think another way to work around this would be to create a wrapper 
header file in which you #include sd-deamon.h, and then pass that 
wrapper header file to jextract.

Jorn

On 13-2-2025 17:51, Nils Kattenbeck wrote:
> Dear all,
>
> Today I tried to use jextract on sd-daemon.h (from systemd) to access 
> the sd_notify* class of functions. To my surprise this did not work 
> and returned in the following error message:
>
> ../jextract-21/bin/jextract --source -t foo.bar 
> /usr/include/systemd/sd-daemon.h
> WARNING: A restricted method in java.lang.foreign.AddressLayout has 
> been called
> WARNING: java.lang.foreign.AddressLayout::withTargetLayout has been 
> called by module org.openjdk.jextract
> WARNING: Use --enable-native-access=org.openjdk.jextract to avoid a 
> warning for this module
>
> /usr/include/systemd/_sd-common.h:23:4: error: "Do not include 
> _sd-common.h directly; it is a private header."
>
> which comes down to the following preprocessor code in _sd-common.h 
> (which is included by sd-daemon.h):
>
> #if defined(__INCLUDE_LEVEL__) && __INCLUDE_LEVEL__ <= 1 && 
> !defined(__COVERITY__)
> # ?error "Do not include _sd-common.h directly; it is a private header."
> #endif
>
> It seems like jextract does not increase the __INCLUDE_LEVEL__ 
> resulting in this error. However, it does seem to define it which 
> makes this more curious.
> The fix would be to either a) not set it at all or b) correctly 
> increment it when parsing files from an? #include statement.
>
> For now I have been able to circumvent this by telling jextract to 
> also define __COVERITY__though this is only a very dirty hack and will 
> not work in every instance.
>
> Cheers,
> Nils
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250214/8217e451/attachment-0001.htm>

From nilskemail at gmail.com  Sat Feb 15 16:46:31 2025
From: nilskemail at gmail.com (Nils Kattenbeck)
Date: Sat, 15 Feb 2025 17:46:31 +0100
Subject: jextract fails to work on sd-daemon.h due to wrong handling of
 __INCLUDE_LEVEL__
In-Reply-To: <9fd8145b-6eaa-4243-897a-7449f414b619@oracle.com>
References: <CAKkJDRdNikfAhR8pkontZU6XaFi0na4jKPxS7Q_fHkp7FKCFuQ@mail.gmail.com>
 <9fd8145b-6eaa-4243-897a-7449f414b619@oracle.com>
Message-ID: <CAKkJDRdW5d=OniJhO-icJTSe6fQQUNCJjCirh4eZi-0AGuJ_qQ@mail.gmail.com>

Hi Jorn,

Your assessment seems to be correct. In C the main.c would be level 0 which
libclang sidesteps in this case. Creating a dummy header file which simply
includes the sd-daemon.h file seems to fix the problem.

That being said I think it would still make sense for jextract to work
around this issue. Given that the resulting Java classes would be similar
to the main translation unit in C it would make sense for jextract to
emulate this behaviour and read the header files as if they already were at
level 1. This could e.g. be done creating such a dummy header file
automatically (like I now did manually). This would better match
expectations, resolve the issue in this specific instance with systemd but
more importantly would prevent hard to troubleshoot issues in the future.

Cheers, Nils

On Fri, Feb 14, 2025 at 11:46?PM Jorn Vernee <jorn.vernee at oracle.com> wrote:

> Hey Nils,
>
> Jextract uses clang under the hood to do the parsing, so it is clang that
> is managing the __INCLUDE_LEVEL__ value, and I'm assuming it does that
> correctly.
>
> I think the issue here is that, normally, you would write a program that
> includes sd-daemon.h, so the include level of that file starts out at 1,
> with the main program translation unit being level 0. But, since jextract
> uses clang to parse the sd-daemon.h file directly, it has include level 0
> instead, and this implementation header seems to end up with include level
> 1, failing the check. You should see the same error if you directly pass
> sd-daemon.h to clang (or gcc).
>
> I think another way to work around this would be to create a wrapper
> header file in which you #include sd-deamon.h, and then pass that wrapper
> header file to jextract.
>
> Jorn
> On 13-2-2025 17:51, Nils Kattenbeck wrote:
>
> Dear all,
>
> Today I tried to use jextract on sd-daemon.h (from systemd) to access the
> sd_notify* class of functions. To my surprise this did not work and
> returned in the following error message:
>
> ../jextract-21/bin/jextract --source -t foo.bar
> /usr/include/systemd/sd-daemon.h
> WARNING: A restricted method in java.lang.foreign.AddressLayout has been
> called
> WARNING: java.lang.foreign.AddressLayout::withTargetLayout has been called
> by module org.openjdk.jextract
> WARNING: Use --enable-native-access=org.openjdk.jextract to avoid a
> warning for this module
>
> /usr/include/systemd/_sd-common.h:23:4: error: "Do not include
> _sd-common.h directly; it is a private header."
>
> which comes down to the following preprocessor code in _sd-common.h (which
> is included by sd-daemon.h):
>
> #if defined(__INCLUDE_LEVEL__) && __INCLUDE_LEVEL__ <= 1 &&
> !defined(__COVERITY__)
> #  error "Do not include _sd-common.h directly; it is a private header."
> #endif
>
> It seems like jextract does not increase the __INCLUDE_LEVEL__ resulting
> in this error. However, it does seem to define it which makes this more
> curious.
> The fix would be to either a) not set it at all or b) correctly increment
> it when parsing files from an  #include statement.
>
> For now I have been able to circumvent this by telling jextract to also
> define __COVERITY__ though this is only a very dirty hack and will not
> work in every instance.
>
> Cheers,
> Nils
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250215/06e1cf0b/attachment.htm>

From maurizio.cimadamore at oracle.com  Mon Feb 17 13:00:16 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 17 Feb 2025 13:00:16 +0000
Subject: jextract fails to work on sd-daemon.h due to wrong handling of
 __INCLUDE_LEVEL__
In-Reply-To: <CAKkJDRdW5d=OniJhO-icJTSe6fQQUNCJjCirh4eZi-0AGuJ_qQ@mail.gmail.com>
References: <CAKkJDRdNikfAhR8pkontZU6XaFi0na4jKPxS7Q_fHkp7FKCFuQ@mail.gmail.com>
 <9fd8145b-6eaa-4243-897a-7449f414b619@oracle.com>
 <CAKkJDRdW5d=OniJhO-icJTSe6fQQUNCJjCirh4eZi-0AGuJ_qQ@mail.gmail.com>
Message-ID: <a22a9468-5534-466f-9733-28f1f1cab7bf@oracle.com>

I wonder how this interacts with the fact that jextract now also accepts 
multiple headers and, in that case, it will generate an intermediate 
header that includes the specified headers.

Can you try passing jextract _two_ headers, both? sd-daemon.h and 
something else, and see what happens? My feeling is that things should 
work in that case.

Which, if true, would advocate for jextract to handle both cases in the 
same way: with an intermediate header including the specified header 
file(s).

Maurizio



On 15/02/2025 16:46, Nils Kattenbeck wrote:
> Hi Jorn,
>
> Your assessment seems to be correct. In C the main.c would be level 0 
> which libclang sidesteps in this case. Creating a dummy header file 
> which simply includes the sd-daemon.h file seems to fix the problem.
>
> That being said I think it would still make sense for jextract to work 
> around this issue. Given that the resulting Java classes would be 
> similar to the main translation unit in C it would make sense for 
> jextract to emulate this behaviour and read the header files as if 
> they already were at level 1. This could e.g. be done creating such a 
> dummy header file automatically (like I now did manually). This would 
> better match expectations, resolve the issue in this specific instance 
> with systemd but more importantly would prevent hard to troubleshoot 
> issues in the future.
>
> Cheers, Nils
>
> On Fri, Feb 14, 2025 at 11:46?PM Jorn Vernee <jorn.vernee at oracle.com> 
> wrote:
>
>     Hey Nils,
>
>     Jextract uses clang under the hood to do the parsing, so it is
>     clang that is managing the __INCLUDE_LEVEL__ value, and I'm
>     assuming it does that correctly.
>
>     I think the issue here is that, normally, you would write a
>     program that includes sd-daemon.h, so the include level of that
>     file starts out at 1, with the main program translation unit being
>     level 0. But, since jextract uses clang to parse the sd-daemon.h
>     file directly, it has include level 0 instead, and this
>     implementation header seems to end up with include level 1,
>     failing the check. You should see the same error if you directly
>     pass sd-daemon.h to clang (or gcc).
>
>     I think another way to work around this would be to create a
>     wrapper header file in which you #include sd-deamon.h, and then
>     pass that wrapper header file to jextract.
>
>     Jorn
>
>     On 13-2-2025 17:51, Nils Kattenbeck wrote:
>>     Dear all,
>>
>>     Today I tried to use jextract on sd-daemon.h (from systemd) to
>>     access the sd_notify* class of functions. To my surprise this did
>>     not work and returned in the following error message:
>>
>>     ../jextract-21/bin/jextract --source -t foo.bar
>>     /usr/include/systemd/sd-daemon.h
>>     WARNING: A restricted method in java.lang.foreign.AddressLayout
>>     has been called
>>     WARNING: java.lang.foreign.AddressLayout::withTargetLayout has
>>     been called by module org.openjdk.jextract
>>     WARNING: Use --enable-native-access=org.openjdk.jextract to avoid
>>     a warning for this module
>>
>>     /usr/include/systemd/_sd-common.h:23:4: error: "Do not include
>>     _sd-common.h directly; it is a private header."
>>
>>     which comes down to the following preprocessor code in
>>     _sd-common.h (which is included by sd-daemon.h):
>>
>>     #if defined(__INCLUDE_LEVEL__) && __INCLUDE_LEVEL__ <= 1 &&
>>     !defined(__COVERITY__)
>>     # ?error "Do not include _sd-common.h directly; it is a private
>>     header."
>>     #endif
>>
>>     It seems like jextract does not increase the __INCLUDE_LEVEL__
>>     resulting in this error. However, it does seem to define it which
>>     makes this more curious.
>>     The fix would be to either a) not set it at all or b) correctly
>>     increment it when parsing files from an #include statement.
>>
>>     For now I have been able to circumvent this by telling jextract
>>     to also define __COVERITY__though this is only a very dirty hack
>>     and will not work in every instance.
>>
>>     Cheers,
>>     Nils
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250217/c59879d0/attachment-0001.htm>

From jorn.vernee at oracle.com  Mon Feb 17 13:03:53 2025
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Mon, 17 Feb 2025 14:03:53 +0100
Subject: jextract fails to work on sd-daemon.h due to wrong handling of
 __INCLUDE_LEVEL__
In-Reply-To: <a22a9468-5534-466f-9733-28f1f1cab7bf@oracle.com>
References: <CAKkJDRdNikfAhR8pkontZU6XaFi0na4jKPxS7Q_fHkp7FKCFuQ@mail.gmail.com>
 <9fd8145b-6eaa-4243-897a-7449f414b619@oracle.com>
 <CAKkJDRdW5d=OniJhO-icJTSe6fQQUNCJjCirh4eZi-0AGuJ_qQ@mail.gmail.com>
 <a22a9468-5534-466f-9733-28f1f1cab7bf@oracle.com>
Message-ID: <75f3f4c7-d29c-4fd4-9471-938280e23ec6@oracle.com>

Looking at the code, we already unconditionally generate an intermediate 
header file [1]. So this should already work on the latest version of 
jextract.

Jorn

[1]: 
https://github.com/openjdk/jextract/blob/7ed79ecdf678db804f40b3494b6f1dafa760c808/src/main/java/org/openjdk/jextract/JextractTool.java#L110

On 17-2-2025 14:00, Maurizio Cimadamore wrote:
>
> I wonder how this interacts with the fact that jextract now also 
> accepts multiple headers and, in that case, it will generate an 
> intermediate header that includes the specified headers.
>
> Can you try passing jextract _two_ headers, both? sd-daemon.h and 
> something else, and see what happens? My feeling is that things should 
> work in that case.
>
> Which, if true, would advocate for jextract to handle both cases in 
> the same way: with an intermediate header including the specified 
> header file(s).
>
> Maurizio
>
>
>
> On 15/02/2025 16:46, Nils Kattenbeck wrote:
>> Hi Jorn,
>>
>> Your assessment seems to be correct. In C the main.c would be level 0 
>> which libclang sidesteps in this case. Creating a dummy header file 
>> which simply includes the sd-daemon.h file seems to fix the problem.
>>
>> That being said I think it would still make sense for jextract to 
>> work around this issue. Given that the resulting Java classes would 
>> be similar to the main translation unit in C it would make sense for 
>> jextract to emulate this behaviour and read the header files as if 
>> they already were at level 1. This could e.g. be done creating such a 
>> dummy header file automatically (like I now did manually). This would 
>> better match expectations, resolve the issue in this specific 
>> instance with systemd but more importantly would prevent hard to 
>> troubleshoot issues in the future.
>>
>> Cheers, Nils
>>
>> On Fri, Feb 14, 2025 at 11:46?PM Jorn Vernee <jorn.vernee at oracle.com> 
>> wrote:
>>
>>     Hey Nils,
>>
>>     Jextract uses clang under the hood to do the parsing, so it is
>>     clang that is managing the __INCLUDE_LEVEL__ value, and I'm
>>     assuming it does that correctly.
>>
>>     I think the issue here is that, normally, you would write a
>>     program that includes sd-daemon.h, so the include level of that
>>     file starts out at 1, with the main program translation unit
>>     being level 0. But, since jextract uses clang to parse the
>>     sd-daemon.h file directly, it has include level 0 instead, and
>>     this implementation header seems to end up with include level 1,
>>     failing the check. You should see the same error if you directly
>>     pass sd-daemon.h to clang (or gcc).
>>
>>     I think another way to work around this would be to create a
>>     wrapper header file in which you #include sd-deamon.h, and then
>>     pass that wrapper header file to jextract.
>>
>>     Jorn
>>
>>     On 13-2-2025 17:51, Nils Kattenbeck wrote:
>>>     Dear all,
>>>
>>>     Today I tried to use jextract on sd-daemon.h (from systemd) to
>>>     access the sd_notify* class of functions. To my surprise this
>>>     did not work and returned in the following error message:
>>>
>>>     ../jextract-21/bin/jextract --source -t foo.bar
>>>     /usr/include/systemd/sd-daemon.h
>>>     WARNING: A restricted method in java.lang.foreign.AddressLayout
>>>     has been called
>>>     WARNING: java.lang.foreign.AddressLayout::withTargetLayout has
>>>     been called by module org.openjdk.jextract
>>>     WARNING: Use --enable-native-access=org.openjdk.jextract to
>>>     avoid a warning for this module
>>>
>>>     /usr/include/systemd/_sd-common.h:23:4: error: "Do not include
>>>     _sd-common.h directly; it is a private header."
>>>
>>>     which comes down to the following preprocessor code in
>>>     _sd-common.h (which is included by sd-daemon.h):
>>>
>>>     #if defined(__INCLUDE_LEVEL__) && __INCLUDE_LEVEL__ <= 1 &&
>>>     !defined(__COVERITY__)
>>>     # ?error "Do not include _sd-common.h directly; it is a private
>>>     header."
>>>     #endif
>>>
>>>     It seems like jextract does not increase the __INCLUDE_LEVEL__
>>>     resulting in this error. However, it does seem to define it
>>>     which makes this more curious.
>>>     The fix would be to either a) not set it at all or b) correctly
>>>     increment it when parsing files from an #include statement.
>>>
>>>     For now I have been able to circumvent this by telling jextract
>>>     to also define __COVERITY__though this is only a very dirty hack
>>>     and will not work in every instance.
>>>
>>>     Cheers,
>>>     Nils
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250217/a45d9e72/attachment.htm>

From nilskemail at gmail.com  Mon Feb 17 13:12:09 2025
From: nilskemail at gmail.com (Nils Kattenbeck)
Date: Mon, 17 Feb 2025 14:12:09 +0100
Subject: jextract fails to work on sd-daemon.h due to wrong handling of
 __INCLUDE_LEVEL__
In-Reply-To: <75f3f4c7-d29c-4fd4-9471-938280e23ec6@oracle.com>
References: <CAKkJDRdNikfAhR8pkontZU6XaFi0na4jKPxS7Q_fHkp7FKCFuQ@mail.gmail.com>
 <9fd8145b-6eaa-4243-897a-7449f414b619@oracle.com>
 <CAKkJDRdW5d=OniJhO-icJTSe6fQQUNCJjCirh4eZi-0AGuJ_qQ@mail.gmail.com>
 <a22a9468-5534-466f-9733-28f1f1cab7bf@oracle.com>
 <75f3f4c7-d29c-4fd4-9471-938280e23ec6@oracle.com>
Message-ID: <CAKkJDRcyk_53omZrLFgT+8Of7j=pki5_s7kM6hHDOcQYS+Bjhw@mail.gmail.com>

Thanks, v22 works. I was checking with jextract 21 as that is the JDK
version I have running. With v22 everything seems to work, both when
specifying one or two header files. There are still a few warnings but
those seem unrelated:

sd-daemon.h:26:1: warning: Skipping
_sd_useless_struct_to_allow_trailing_semicolon_ (type
Declared(_sd_useless_struct_to_allow_trailing_semicolon_) is not supported)


Cheers, Nils

On Mon, Feb 17, 2025 at 2:04?PM Jorn Vernee <jorn.vernee at oracle.com> wrote:

> Looking at the code, we already unconditionally generate an intermediate
> header file [1]. So this should already work on the latest version of
> jextract.
>
> Jorn
>
> [1]:
> https://github.com/openjdk/jextract/blob/7ed79ecdf678db804f40b3494b6f1dafa760c808/src/main/java/org/openjdk/jextract/JextractTool.java#L110
> On 17-2-2025 14:00, Maurizio Cimadamore wrote:
>
> I wonder how this interacts with the fact that jextract now also accepts
> multiple headers and, in that case, it will generate an intermediate header
> that includes the specified headers.
>
> Can you try passing jextract _two_ headers, both  sd-daemon.h and
> something else, and see what happens? My feeling is that things should work
> in that case.
>
> Which, if true, would advocate for jextract to handle both cases in the
> same way: with an intermediate header including the specified header
> file(s).
>
> Maurizio
>
>
>
> On 15/02/2025 16:46, Nils Kattenbeck wrote:
>
> Hi Jorn,
>
> Your assessment seems to be correct. In C the main.c would be level 0
> which libclang sidesteps in this case. Creating a dummy header file which
> simply includes the sd-daemon.h file seems to fix the problem.
>
> That being said I think it would still make sense for jextract to work
> around this issue. Given that the resulting Java classes would be similar
> to the main translation unit in C it would make sense for jextract to
> emulate this behaviour and read the header files as if they already were at
> level 1. This could e.g. be done creating such a dummy header file
> automatically (like I now did manually). This would better match
> expectations, resolve the issue in this specific instance with systemd but
> more importantly would prevent hard to troubleshoot issues in the future.
>
> Cheers, Nils
>
> On Fri, Feb 14, 2025 at 11:46?PM Jorn Vernee <jorn.vernee at oracle.com>
> wrote:
>
>> Hey Nils,
>>
>> Jextract uses clang under the hood to do the parsing, so it is clang that
>> is managing the __INCLUDE_LEVEL__ value, and I'm assuming it does that
>> correctly.
>>
>> I think the issue here is that, normally, you would write a program that
>> includes sd-daemon.h, so the include level of that file starts out at 1,
>> with the main program translation unit being level 0. But, since jextract
>> uses clang to parse the sd-daemon.h file directly, it has include level 0
>> instead, and this implementation header seems to end up with include level
>> 1, failing the check. You should see the same error if you directly pass
>> sd-daemon.h to clang (or gcc).
>>
>> I think another way to work around this would be to create a wrapper
>> header file in which you #include sd-deamon.h, and then pass that
>> wrapper header file to jextract.
>>
>> Jorn
>> On 13-2-2025 17:51, Nils Kattenbeck wrote:
>>
>> Dear all,
>>
>> Today I tried to use jextract on sd-daemon.h (from systemd) to access the
>> sd_notify* class of functions. To my surprise this did not work and
>> returned in the following error message:
>>
>> ../jextract-21/bin/jextract --source -t foo.bar
>> /usr/include/systemd/sd-daemon.h
>> WARNING: A restricted method in java.lang.foreign.AddressLayout has been
>> called
>> WARNING: java.lang.foreign.AddressLayout::withTargetLayout has been
>> called by module org.openjdk.jextract
>> WARNING: Use --enable-native-access=org.openjdk.jextract to avoid a
>> warning for this module
>>
>> /usr/include/systemd/_sd-common.h:23:4: error: "Do not include
>> _sd-common.h directly; it is a private header."
>>
>> which comes down to the following preprocessor code in _sd-common.h
>> (which is included by sd-daemon.h):
>>
>> #if defined(__INCLUDE_LEVEL__) && __INCLUDE_LEVEL__ <= 1 &&
>> !defined(__COVERITY__)
>> #  error "Do not include _sd-common.h directly; it is a private header."
>> #endif
>>
>> It seems like jextract does not increase the __INCLUDE_LEVEL__ resulting
>> in this error. However, it does seem to define it which makes this more
>> curious.
>> The fix would be to either a) not set it at all or b) correctly increment
>> it when parsing files from an  #include statement.
>>
>> For now I have been able to circumvent this by telling jextract to also
>> define __COVERITY__ though this is only a very dirty hack and will not
>> work in every instance.
>>
>> Cheers,
>> Nils
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250217/39c779e8/attachment-0001.htm>

From maurizio.cimadamore at oracle.com  Mon Feb 17 13:36:16 2025
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 17 Feb 2025 13:36:16 +0000
Subject: jextract fails to work on sd-daemon.h due to wrong handling of
 __INCLUDE_LEVEL__
In-Reply-To: <75f3f4c7-d29c-4fd4-9471-938280e23ec6@oracle.com>
References: <CAKkJDRdNikfAhR8pkontZU6XaFi0na4jKPxS7Q_fHkp7FKCFuQ@mail.gmail.com>
 <9fd8145b-6eaa-4243-897a-7449f414b619@oracle.com>
 <CAKkJDRdW5d=OniJhO-icJTSe6fQQUNCJjCirh4eZi-0AGuJ_qQ@mail.gmail.com>
 <a22a9468-5534-466f-9733-28f1f1cab7bf@oracle.com>
 <75f3f4c7-d29c-4fd4-9471-938280e23ec6@oracle.com>
Message-ID: <f526736e-b2fa-434c-abbd-60b3cfe7c09b@oracle.com>

Phew :-)

On 17/02/2025 13:03, Jorn Vernee wrote:
> Looking at the code, we already unconditionally generate an 
> intermediate header file [1]


@Nils - thanks for confirming!

Maurizio


From jorn.vernee at oracle.com  Mon Feb 17 14:56:27 2025
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Mon, 17 Feb 2025 15:56:27 +0100
Subject: [External] : Re: jextract fails to work on sd-daemon.h due to
 wrong handling of __INCLUDE_LEVEL__
In-Reply-To: <CAKkJDRcyk_53omZrLFgT+8Of7j=pki5_s7kM6hHDOcQYS+Bjhw@mail.gmail.com>
References: <CAKkJDRdNikfAhR8pkontZU6XaFi0na4jKPxS7Q_fHkp7FKCFuQ@mail.gmail.com>
 <9fd8145b-6eaa-4243-897a-7449f414b619@oracle.com>
 <CAKkJDRdW5d=OniJhO-icJTSe6fQQUNCJjCirh4eZi-0AGuJ_qQ@mail.gmail.com>
 <a22a9468-5534-466f-9733-28f1f1cab7bf@oracle.com>
 <75f3f4c7-d29c-4fd4-9471-938280e23ec6@oracle.com>
 <CAKkJDRcyk_53omZrLFgT+8Of7j=pki5_s7kM6hHDOcQYS+Bjhw@mail.gmail.com>
Message-ID: <1cb24320-f5e6-44cb-9fd0-f1fe6e09b59a@oracle.com>

Yes, that warning is unrelated. It likely means that 
_sd_useless_struct_to_allow_trailing_semicolon_is only a declaration 
that does not have a definition, so no bindings will be generated for it.

Jorn

On 17-2-2025 14:12, Nils Kattenbeck wrote:
> Thanks, v22 works. I was checking with jextract 21 as that is the JDK 
> version I have running. With v22 everything seems to work, both when 
> specifying one or two header files. There are still a few warnings but 
> those seem unrelated:
>
> sd-daemon.h:26:1: warning: Skipping 
> _sd_useless_struct_to_allow_trailing_semicolon_ (type 
> Declared(_sd_useless_struct_to_allow_trailing_semicolon_) is not 
> supported)
>
>
> Cheers, Nils
>
> On Mon, Feb 17, 2025 at 2:04?PM Jorn Vernee <jorn.vernee at oracle.com> 
> wrote:
>
>     Looking at the code, we already unconditionally generate an
>     intermediate header file [1]. So this should already work on the
>     latest version of jextract.
>
>     Jorn
>
>     [1]:
>     https://github.com/openjdk/jextract/blob/7ed79ecdf678db804f40b3494b6f1dafa760c808/src/main/java/org/openjdk/jextract/JextractTool.java#L110
>     <https://urldefense.com/v3/__https://github.com/openjdk/jextract/blob/7ed79ecdf678db804f40b3494b6f1dafa760c808/src/main/java/org/openjdk/jextract/JextractTool.java*L110__;Iw!!ACWV5N9M2RV99hQ!Iw0EA9Y9KDQAmnT1W734TK58GyrdlXU9udm4XBJYBuYjQwu9PftFnhLsLnywJZ4adAjR2S4WJH1D6l4innKM$>
>
>     On 17-2-2025 14:00, Maurizio Cimadamore wrote:
>>
>>     I wonder how this interacts with the fact that jextract now also
>>     accepts multiple headers and, in that case, it will generate an
>>     intermediate header that includes the specified headers.
>>
>>     Can you try passing jextract _two_ headers, both sd-daemon.h and
>>     something else, and see what happens? My feeling is that things
>>     should work in that case.
>>
>>     Which, if true, would advocate for jextract to handle both cases
>>     in the same way: with an intermediate header including the
>>     specified header file(s).
>>
>>     Maurizio
>>
>>
>>
>>     On 15/02/2025 16:46, Nils Kattenbeck wrote:
>>>     Hi Jorn,
>>>
>>>     Your assessment seems to be correct. In C the main.c would be
>>>     level 0 which libclang sidesteps in this case. Creating a dummy
>>>     header file which simply includes the sd-daemon.h file seems to
>>>     fix the problem.
>>>
>>>     That being said I think it would still make sense for jextract
>>>     to work around this issue. Given that the resulting Java classes
>>>     would be similar to the main translation unit in C it would make
>>>     sense for jextract to emulate this behaviour and read the header
>>>     files as if they already were at level 1. This could e.g. be
>>>     done creating such a dummy header file automatically (like I now
>>>     did manually). This would better match expectations, resolve the
>>>     issue in this specific instance with systemd but more
>>>     importantly would prevent hard to troubleshoot issues in the future.
>>>
>>>     Cheers, Nils
>>>
>>>     On Fri, Feb 14, 2025 at 11:46?PM Jorn Vernee
>>>     <jorn.vernee at oracle.com> wrote:
>>>
>>>         Hey Nils,
>>>
>>>         Jextract uses clang under the hood to do the parsing, so it
>>>         is clang that is managing the __INCLUDE_LEVEL__ value, and
>>>         I'm assuming it does that correctly.
>>>
>>>         I think the issue here is that, normally, you would write a
>>>         program that includes sd-daemon.h, so the include level of
>>>         that file starts out at 1, with the main program translation
>>>         unit being level 0. But, since jextract uses clang to parse
>>>         the sd-daemon.h file directly, it has include level 0
>>>         instead, and this implementation header seems to end up with
>>>         include level 1, failing the check. You should see the same
>>>         error if you directly pass sd-daemon.h to clang (or gcc).
>>>
>>>         I think another way to work around this would be to create a
>>>         wrapper header file in which you #include sd-deamon.h, and
>>>         then pass that wrapper header file to jextract.
>>>
>>>         Jorn
>>>
>>>         On 13-2-2025 17:51, Nils Kattenbeck wrote:
>>>>         Dear all,
>>>>
>>>>         Today I tried to use jextract on sd-daemon.h (from systemd)
>>>>         to access the sd_notify* class of functions. To my surprise
>>>>         this did not work and returned in the following error message:
>>>>
>>>>         ../jextract-21/bin/jextract --source -t foo.bar
>>>>         /usr/include/systemd/sd-daemon.h
>>>>         WARNING: A restricted method in
>>>>         java.lang.foreign.AddressLayout has been called
>>>>         WARNING: java.lang.foreign.AddressLayout::withTargetLayout
>>>>         has been called by module org.openjdk.jextract
>>>>         WARNING: Use --enable-native-access=org.openjdk.jextract to
>>>>         avoid a warning for this module
>>>>
>>>>         /usr/include/systemd/_sd-common.h:23:4: error: "Do not
>>>>         include _sd-common.h directly; it is a private header."
>>>>
>>>>         which comes down to the following preprocessor code in
>>>>         _sd-common.h (which is included by sd-daemon.h):
>>>>
>>>>         #if defined(__INCLUDE_LEVEL__) && __INCLUDE_LEVEL__ <= 1 &&
>>>>         !defined(__COVERITY__)
>>>>         # ?error "Do not include _sd-common.h directly; it is a
>>>>         private header."
>>>>         #endif
>>>>
>>>>         It seems like jextract does not increase the
>>>>         __INCLUDE_LEVEL__ resulting in this error. However, it does
>>>>         seem to define it which makes this more curious.
>>>>         The fix would be to either a) not set it at all or b)
>>>>         correctly increment it when parsing files from an? #include
>>>>         statement.
>>>>
>>>>         For now I have been able to circumvent this by telling
>>>>         jextract to also define __COVERITY__though this is only a
>>>>         very dirty hack and will not work in every instance.
>>>>
>>>>         Cheers,
>>>>         Nils
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250217/ad636ec4/attachment-0001.htm>

From lain at null.net  Wed Feb 26 02:13:05 2025
From: lain at null.net (Lain Lain)
Date: Wed, 26 Feb 2025 03:13:05 +0100
Subject: ffmbindings manual bindings to C++
Message-ID: <trinity-1f62d70a-15ac-45e2-be8d-7cf11deba548-1740535984984@3c-app-mailcom-lxa06>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250226/327e3708/attachment.htm>

From jorn.vernee at oracle.com  Thu Feb 27 15:58:35 2025
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Thu, 27 Feb 2025 16:58:35 +0100
Subject: ffmbindings manual bindings to C++
In-Reply-To: <trinity-1f62d70a-15ac-45e2-be8d-7cf11deba548-1740535984984@3c-app-mailcom-lxa06>
References: <trinity-1f62d70a-15ac-45e2-be8d-7cf11deba548-1740535984984@3c-app-mailcom-lxa06>
Message-ID: <1c827663-29fe-465f-9db3-85005da3ce91@oracle.com>

Hello,

I had a quick look, and just want to note about the difference between 
the result of `sizeof` and `MemoryLayout::byteSize`. From what I've 
seen, compilers typically pad out the end of a struct so that it can be 
aligned when placed in an array, and this can be observed when using 
PAHole, or the MSVC debugging flags. i.e. this seems to be more than 
just a quirk of the sizeof operator. If you want the same result using 
the layout API, you have to add this trailing padding:

     MemoryLayout.structLayout(
         ValueLayout.JAVA_DOUBLE.withName("d1_"),
         ValueLayout.JAVA_DOUBLE.withName("d2_"),
         ValueLayout.JAVA_INT.withName("type_"),
         MemoryLayout.paddingLayout(4));

Jorn

On 26-2-2025 03:13, Lain Lain wrote:
> Hi,
> We would like to present you ffmbindings project which helps to do 
> manual bindings to C++ libraries from Java using FFM.
> Currently it contains bindings to eigen C++ library but we are going 
> to publish few more this month.
> Source code: https://bitbucket.org/ffmbindings
> Documentation: https://ffmbindings.onrender.com
> Any feedback are welcome.
> Thank you,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250227/86012fd7/attachment.htm>