From lain at null.net Sat Mar 1 01:44:01 2025 From: lain at null.net (Lain Lain) Date: Sat, 1 Mar 2025 02:44:01 +0100 Subject: ffmbindings manual bindings to C++ In-Reply-To: <1c827663-29fe-465f-9db3-85005da3ce91@oracle.com> References: <1c827663-29fe-465f-9db3-85005da3ce91@oracle.com> Message-ID: An HTML attachment was scrubbed... URL: From lain at null.net Tue Mar 4 01:36:59 2025 From: lain at null.net (Lain Lain) Date: Tue, 4 Mar 2025 02:36:59 +0100 Subject: ffmbindings manual bindings to C++ In-Reply-To: <1c827663-29fe-465f-9db3-85005da3ce91@oracle.com> References: <1c827663-29fe-465f-9db3-85005da3ce91@oracle.com> Message-ID: Hi all, We have published new bindings to GNU libstdc++ called ffmbindings.stdcpp: Source code: https://bitbucket.org/ffmbindings/ffmbindings-stdcpp Documentation: https://ffmbindings.onrender.com/javadoc/ffmbindings.stdcpp/index.html Many C++ libraries use some of the types defined inside libstdc++ as part of their APIs. Popular examples of such types are std::string, std::shared_ptr and of course STL types like std::vector etc. Therefore, to create bindings to such C++ libraries it is important to cover libstdc++ types. ffmbindings.stdcpp covers some of libstdc++ types. Users can create such types in Java and pass them directly to C++ APIs bindings they create. For example, to create std::string object: new StdStringFactory().create("java string") Thank you, 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[https://ffmbindings.onrender.com] ? Any feedback are welcome. ? Thank you, From maurizio.cimadamore at oracle.com Tue Mar 4 12:19:44 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 4 Mar 2025 12:19:44 +0000 Subject: ffmbindings manual bindings to C++ In-Reply-To: References: Message-ID: Hi Lain, this is some interesting work. When looking at the documentation, and at the examples provided, it is not clear to me how some features of C++ are supported. E.g. it seems to me that the bindings you create (esp. downcall handles) are completely static. That is, if you have B extends A, and both A and B define a virtual method, you will add a downcall handle in both classes, one for A and the other for B . Then you kind of rely on /Java's/ (not C++'s !!) dynamic dispatch to make things work -- e.g. when you call A on an instance of B, the JVM will call B -- which will result in the correct C++ method being invoked. While this works for simple examples -- I'm a bit skeptical about the generality of this approach. Of course, as long as there's no multiple inheritance, and as long as all the C++ classes are created from the Java side of the fence, this might even work correctly. But if some C++ method returns some A* -- what Java wrapper will we create? The problem here is that the choice of the wrapper (A vs. B) determines which set of methods will be invoked on that instance (because we're effectively bypassing C++'s virtual dispatch). All things considered, this approach doesn't seem very different from the jextract PoC I shared -- in the sense that it models some C++ features /to some degree/ without really providing full language interop support which, IMHO, is not possible w/o having a C++ compiler on your side (inline functions are another issue). But maybe, what you are trying to say is that, even with a simple PoC like the one I provided, it's possible to provide meaningful interop for at least /some/ C++ libraries (like eigen) ? Cheers Maurizio On 26/02/2025 02: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: From maurizio.cimadamore at oracle.com Tue Mar 4 12:21:06 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 4 Mar 2025 12:21:06 +0000 Subject: ffmbindings manual bindings to C++ In-Reply-To: References: Message-ID: <67bb6b7c-7fab-4d50-9c00-edeb7943a982@oracle.com> Sorry for the formatting -- dunno what happened. Let me try again: Hi Lain, this is some interesting work. When looking at the documentation, and at the examples provided, it is not clear to me how some features of C++ are supported. E.g. it seems to me that the bindings you create (esp. downcall handles) are completely static. That is, if you have B extends A, and both A and B define a virtual method, you will add a downcall handle in both classes, one for A and the other for B. Then you kind of rely on /Java's/ (not C++'s !!) dynamic dispatch to make things work -- e.g. when you call A on an instance of B, the JVM will call B -- which will result in the correct C++ method being invoked. While this works for simple examples -- I'm a bit skeptical about the generality of this approach. Of course, as long as there's no multiple inheritance, and as long as all the C++ classes are created from the Java side of the fence, this might even work correctly. But if some C++ method returns some A* -- what Java wrapper will we create? The problem here is that the choice of the wrapper (A vs. B) determines which set of methods will be invoked on that instance (because we're effectively bypassing C++'s virtual dispatch). All things considered, this approach doesn't seem very different from the jextract PoC I shared -- in the sense that it models some C++ features /to some degree/ without really providing full language interop support which, IMHO, is not possible w/o having a C++ compiler on your side (inline functions are another issue). But maybe, what you are trying to say is that, even with a simple PoC like the one I provided, it's possible to provide meaningful interop for at least /some/ C++ libraries (like eigen) ? Cheers Maurizio On 04/03/2025 12:19, Maurizio Cimadamore wrote: > > Hi Lain, this is some interesting work. When looking at the > documentation, and at the examples provided, it is not clear to me how > some features of C++ are supported. E.g. it seems to me that the > bindings you create (esp. downcall handles) are completely static. > That is, if you have B extends A, and both A and B define a virtual > method, you will add a downcall handle in both classes, one for A > > and the other for B > > . Then you kind of rely on /Java's/ (not C++'s !!) dynamic dispatch to > make things work -- e.g. when you call A > > on an instance of B, the JVM will call B > > -- which will result in the correct C++ method being invoked. While > this works for simple examples -- I'm a bit skeptical about the > generality of this approach. Of course, as long as there's no multiple > inheritance, and as long as all the C++ classes are created from the > Java side of the fence, this might even work correctly. > > But if some C++ method returns some A* -- what Java wrapper will we > create? The problem here is that the choice of the wrapper (A vs. B) > determines which set of methods will be invoked on that instance > (because we're effectively bypassing C++'s virtual dispatch). > > All things considered, this approach doesn't seem very different from > the jextract PoC I shared -- in the sense that it models some C++ > features /to some degree/ without really providing full language > interop support which, IMHO, is not possible w/o having a C++ compiler > on your side (inline functions are another issue). But maybe, what you > are trying to say is that, even with a simple PoC like the one I > provided, it's possible to provide meaningful interop for at least > /some/ C++ libraries (like eigen) ? > > Cheers Maurizio > > On 26/02/2025 02: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: From nbenalla at openjdk.org Tue Mar 4 15:09:23 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 4 Mar 2025 15:09:23 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v4] In-Reply-To: References: Message-ID: > 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 with a new target base due to a merge or a rebase. The pull request now contains six commits: - Respond to feedback, Update Guide - Merge branch 'refs/heads/master' into jextract-mac-os # Conflicts: # src/main/resources/org/openjdk/jextract/impl/resources/Messages.properties - Merge remote-tracking branch 'upstream/master' into jextract-mac-os - use consistent spacing - Fix typos, rename some methods and bump copyright year to 2025 - add mac os support ------------- Changes: https://git.openjdk.org/jextract/pull/268/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=03 Stats: 127 lines in 6 files changed: 78 ins; 24 del; 25 mod Patch: https://git.openjdk.org/jextract/pull/268.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/268/head:pull/268 PR: https://git.openjdk.org/jextract/pull/268 From nbenalla at openjdk.org Tue Mar 4 15:15:45 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 4 Mar 2025 15:15:45 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v5] In-Reply-To: References: Message-ID: > 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: remove unused message (shouldn't have been added) ------------- Changes: - all: https://git.openjdk.org/jextract/pull/268/files - new: https://git.openjdk.org/jextract/pull/268/files/436c4601..46b4a1d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=04 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=03-04 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jextract/pull/268.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/268/head:pull/268 PR: https://git.openjdk.org/jextract/pull/268 From nbenalla at openjdk.org Tue Mar 4 15:38:16 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 4 Mar 2025 15:38:16 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v5] In-Reply-To: References: Message-ID: On Tue, 4 Mar 2025 15:15:45 GMT, Nizar Benalla 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: > > remove unused message (shouldn't have been added) Sorry for the delayed update. I've made some changes based on the review comments. -I've updated the Guide and list of options, they are no longer split into two. -No longer emit warnings if the mac os options are used on a different platform. -This feature should work with custom frameworks, I haven't tested it yet but I will try. -If `--use-system-load-library` option is used without `-l`, a warning is emitted. This can be handled at the parsing level but checking when adding options to the builder seemed simpler. ------------- PR Comment: https://git.openjdk.org/jextract/pull/268#issuecomment-2698049761 From lain at null.net Wed Mar 5 05:30:00 2025 From: lain at null.net (Lain Lain) Date: Wed, 5 Mar 2025 06:30:00 +0100 Subject: ffmbindings manual bindings to C++ In-Reply-To: <67bb6b7c-7fab-4d50-9c00-edeb7943a982@oracle.com> References: <67bb6b7c-7fab-4d50-9c00-edeb7943a982@oracle.com> Message-ID: Hi Maurizio, > But if some C++ method returns some A* -- what Java wrapper will we create? The problem here is that the choice of the wrapper (A vs. B) determines which set of methods will be invoked on that instance (because we're effectively bypassing C++'s virtual dispatch). You are right. It seems this is caused due to C++ type erasure, which happens when C++ object is returned from C++ to Java. Surprisingly, we did not come across this yet but this indeed very common issue. Possibly it can be addressed by parsing vtable and deciding which Java class (A or B) should be mapped back to the returned pointer. We will document it for future investigations. > But maybe, what you are trying to say is that, even with a simple PoC like the one I provided, it's possible to provide meaningful interop for at least /some/ C++ libraries (like eigen) ? Yes. Sometimes creating JNI only to use single class from some C++ library sounds like too much work. > IMHO, is not possible w/o having a C++ compiler on your side (inline functions are another issue). Do we know if someone is working with C++ committee to include new keywords to C++ to help creating bindings? This is not only Java but many other languages could benefit from (Rust, ...) For example, inline functions are mainly for optimization purposes. If compilers knew that inline function may be accessed from other languages they could, in addition to inlining it everywhere, preserve the original function so that bindings could access it. Something like keyword "extern" which we already have. Regards, ? ? Sent:?Tuesday, March 04, 2025 at 12:21 PM From:?"Maurizio Cimadamore" To:?"Lain Lain" , jextract-dev at openjdk.org Subject:?Re: ffmbindings manual bindings to C++ Sorry for the formatting -- dunno what happened. Let me try again: Hi Lain, this is some interesting work. When looking at the documentation, and at the examples provided, it is not clear to me how some features of C++ are supported. E.g. it seems to me that the bindings you create (esp. downcall handles) are completely static. That is, if you have B extends A, and both A and B define a virtual method, you will add a downcall handle in both classes, one for A and the other for B. Then you kind of rely on Java's (not C++'s !!) dynamic dispatch to make things work -- e.g. when you call A on an instance of B, the JVM will call B -- which will result in the correct C++ method being invoked. While this works for simple examples -- I'm a bit skeptical about the generality of this approach. Of course, as long as there's no multiple inheritance, and as long as all the C++ classes are created from the Java side of the fence, this might even work correctly. But if some C++ method returns some A* -- what Java wrapper will we create? The problem here is that the choice of the wrapper (A vs. B) determines which set of methods will be invoked on that instance (because we're effectively bypassing C++'s virtual dispatch). All things considered, this approach doesn't seem very different from the jextract PoC I shared -- in the sense that it models some C++ features to some degree without really providing full language interop support which, IMHO, is not possible w/o having a C++ compiler on your side (inline functions are another issue). But maybe, what you are trying to say is that, even with a simple PoC like the one I provided, it's possible to provide meaningful interop for at least some C++ libraries (like eigen) ? Cheers Maurizio ? On 04/03/2025 12:19, Maurizio Cimadamore wrote:? Hi Lain, this is some interesting work. When looking at the documentation, and at the examples provided, it is not clear to me how some features of C++ are supported. E.g. it seems to me that the bindings you create (esp. downcall handles) are completely static. That is, if you have B extends A, and both A and B define a virtual method, you will add a downcall handle in both classes, one for A and the other for B . Then you kind of rely on Java's (not C++'s !!) dynamic dispatch to make things work -- e.g. when you call A on an instance of B, the JVM will call B -- which will result in the correct C++ method being invoked. While this works for simple examples -- I'm a bit skeptical about the generality of this approach. Of course, as long as there's no multiple inheritance, and as long as all the C++ classes are created from the Java side of the fence, this might even work correctly. But if some C++ method returns some A* -- what Java wrapper will we create? The problem here is that the choice of the wrapper (A vs. B) determines which set of methods will be invoked on that instance (because we're effectively bypassing C++'s virtual dispatch). All things considered, this approach doesn't seem very different from the jextract PoC I shared -- in the sense that it models some C++ features to some degree without really providing full language interop support which, IMHO, is not possible w/o having a C++ compiler on your side (inline functions are another issue). But maybe, what you are trying to say is that, even with a simple PoC like the one I provided, it's possible to provide meaningful interop for at least some C++ libraries (like eigen) ? Cheers Maurizio On 26/02/2025 02: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[https://ffmbindings.onrender.com] ? Any feedback are welcome. ? Thank you, ​ ? From jvernee at openjdk.org Wed Mar 5 10:45:12 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 5 Mar 2025 10:45:12 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v4] In-Reply-To: References: Message-ID: On Tue, 4 Mar 2025 15:09:23 GMT, Nizar Benalla 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 with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Respond to feedback, Update Guide > - Merge branch 'refs/heads/master' into jextract-mac-os > > # Conflicts: > # src/main/resources/org/openjdk/jextract/impl/resources/Messages.properties > - Merge remote-tracking branch 'upstream/master' into jextract-mac-os > - use consistent spacing > - Fix typos, rename some methods and bump copyright year to 2025 > - add mac os support doc/GUIDE.md line 991: > 989: | `--version` | print version information and exit | > 990: | `--macos-framework ` (macOs only) | specify the framework directory include files
defaults to the current Mac OS X SDK dir
This removes the need of having a compile_flags.txt with the required `-framework XYZ` options in the folder where jextract is ran | > 991: | `-f ` (macOs only) | specify the name of the library, path will be expanded to that of the framework folder | I don't think we should mention the workaround using `compile_flags.txt` here. This won't make sense to users who are not familiar with it, and after this change, there's no need for the workaround. src/main/java/org/openjdk/jextract/JextractTool.java line 364: > 362: parser.accepts("--version", "help.version", false); > 363: parser.accepts("--macos-framework", "help.mac.framework", true); > 364: parser.accepts("-f", "help.framework.library.path", true); In clang these are named `-F` and `-framework` [1] (there's no `-f`). I think we should just match that. We did the same for `-D`, `-I` and `-l` to an extent. [1]: https://clang.llvm.org/docs/ClangCommandLineReference.html src/main/java/org/openjdk/jextract/JextractTool.java line 605: > 603: private String formatFrameworkPath(String optionString) { > 604: String publicPath = String.format("/System/Library/Frameworks/%1$s.framework/", optionString); > 605: String privatePath = String.format("/System/Library/PrivateFrameworks/%1$s.framework/", optionString); I think Maurizios comment still applies. AFAIU we need to pass the exact framework path to `dlopen`, so we need to manually search for the frameworks in this system location, and also in the locations specified through `-F`, and then load it from one of those locations. ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1981113429 PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1981125001 PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1981134871 From jvernee at openjdk.org Wed Mar 5 10:46:37 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 5 Mar 2025 10:46:37 GMT Subject: RFR: Gradle 8.11.1 update cleanups [v2] In-Reply-To: References: Message-ID: > Some things were missed as part of: https://github.com/openjdk/jextract/pull/264 > > - The action to validate the gradle wrapper accidentally uses a deprecated version > - The readme was not updated. Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into GradleCleanup - update readme - use non-deprecated action to validate gradle wrapper ------------- Changes: https://git.openjdk.org/jextract/pull/272/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=272&range=01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jextract/pull/272.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/272/head:pull/272 PR: https://git.openjdk.org/jextract/pull/272 From maurizio.cimadamore at oracle.com Wed Mar 5 11:32:36 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 5 Mar 2025 11:32:36 +0000 Subject: ffmbindings manual bindings to C++ In-Reply-To: References: <67bb6b7c-7fab-4d50-9c00-edeb7943a982@oracle.com> Message-ID: Hi, I'm not an expert here -- but I see there's some options to force the compiler to emit symbols for inline functions. For instance I see this: > -fkeep-inline-functions > ?????????? In C, emit "static" functions that are declared "inline" > into the > ?????????? object file, even if the function has been inlined into all > of its > ?????????? callers.? This switch does not affect functions using the > "extern > ?????????? inline" extension in GNU C90.? In C++, emit any and all inline > ?????????? functions into the object file. I've seen also some pragmas being mentioned -- such as this: https://clang.llvm.org/docs/AttributeReference.html#used Of course your mileage might vary -- different compilers might support different options, or work in slightly different ways. And -- the problem is that you have little/no control over whether inline symbols are emitted or not. E.g. if you install a C++ lib on your system, inline functions will either be there, or they won't. If they aren't there there's not much you can do to alter that, except creating a shim library which re-exports the inline symbols. But at that point you are no longer in "pure" Java. I think the shim library approach is actually not a bad idea -- especially the generation of such a shim library could be automated completely -- e.g. some sort of C++ to C transpiler. But, unfortunately, while there have been many experiments along those lines, they all seem to be abandoned at some point (typically when they get to exceptions and/or templates :-) ). Maurizio On 05/03/2025 05:30, Lain Lain wrote: > Do we know if someone is working with C++ committee to include new > keywords to C++ to help creating bindings? This is not only Java but > many other languages could benefit from (Rust, ...) > For example, inline functions are mainly for optimization purposes. If > compilers knew that inline function may be accessed from other languages > they could, in addition to inlining it everywhere, preserve the > original function so that bindings could access it. Something like > keyword "extern" which we already have. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcimadamore at openjdk.org Wed Mar 5 12:39:07 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 5 Mar 2025 12:39:07 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v4] In-Reply-To: References: Message-ID: On Wed, 5 Mar 2025 10:29:28 GMT, Jorn Vernee wrote: >> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Respond to feedback, Update Guide >> - Merge branch 'refs/heads/master' into jextract-mac-os >> >> # Conflicts: >> # src/main/resources/org/openjdk/jextract/impl/resources/Messages.properties >> - Merge remote-tracking branch 'upstream/master' into jextract-mac-os >> - use consistent spacing >> - Fix typos, rename some methods and bump copyright year to 2025 >> - add mac os support > > src/main/java/org/openjdk/jextract/JextractTool.java line 364: > >> 362: parser.accepts("--version", "help.version", false); >> 363: parser.accepts("--macos-framework", "help.mac.framework", true); >> 364: parser.accepts("-f", "help.framework.library.path", true); > > In clang these are named `-F` and `-framework` [1] (there's no `-f`). I think we should just match that. We did the same for `-D`, `-I` and `-l` to an extent. > > [1]: https://clang.llvm.org/docs/ClangCommandLineReference.html I mean -- if one has a prefix `macos-` the other should too -- or none should have it. ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1981319907 From mcimadamore at openjdk.org Wed Mar 5 12:42:06 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 5 Mar 2025 12:42:06 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v4] In-Reply-To: References: Message-ID: On Wed, 5 Mar 2025 12:36:26 GMT, Maurizio Cimadamore wrote: >> src/main/java/org/openjdk/jextract/JextractTool.java line 364: >> >>> 362: parser.accepts("--version", "help.version", false); >>> 363: parser.accepts("--macos-framework", "help.mac.framework", true); >>> 364: parser.accepts("-f", "help.framework.library.path", true); >> >> In clang these are named `-F` and `-framework` [1] (there's no `-f`). I think we should just match that. We did the same for `-D`, `-I` and `-l` to an extent. >> >> [1]: https://clang.llvm.org/docs/ClangCommandLineReference.html > > I mean -- if one has a prefix `macos-` the other should too -- or none should have it. Also, `-f` usually is used in conjunction with other options e.g. `-fmove-loop-invariants`. Which is probably the reason behind the capital letter `-F`. ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1981323989 From mcimadamore at openjdk.org Wed Mar 5 12:45:06 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 5 Mar 2025 12:45:06 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v4] In-Reply-To: References: Message-ID: On Wed, 5 Mar 2025 10:35:56 GMT, Jorn Vernee wrote: >> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Respond to feedback, Update Guide >> - Merge branch 'refs/heads/master' into jextract-mac-os >> >> # Conflicts: >> # src/main/resources/org/openjdk/jextract/impl/resources/Messages.properties >> - Merge remote-tracking branch 'upstream/master' into jextract-mac-os >> - use consistent spacing >> - Fix typos, rename some methods and bump copyright year to 2025 >> - add mac os support > > src/main/java/org/openjdk/jextract/JextractTool.java line 605: > >> 603: private String formatFrameworkPath(String optionString) { >> 604: String publicPath = String.format("/System/Library/Frameworks/%1$s.framework/", optionString); >> 605: String privatePath = String.format("/System/Library/PrivateFrameworks/%1$s.framework/", optionString); > > I think Maurizios comment still applies. AFAIU we need to pass the exact framework path to `dlopen`, so we need to manually search for the frameworks in this system location, and also in the locations specified through `-F`, and then load it from one of those locations. Yep -- it seems to me that public/private paths are _default_ framework paths. But user can add more paths to that list, using `-F`. Btw, one related question here is what is the expected priority of the search -- e.g. should we look into `-F` paths first, and then use public/private paths as fallbacks or the other way around? ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1981329275 From nbenalla at openjdk.org Wed Mar 5 14:33:08 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 5 Mar 2025 14:33:08 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v4] In-Reply-To: References: Message-ID: On Wed, 5 Mar 2025 12:39:19 GMT, Maurizio Cimadamore wrote: >> I mean -- if one has a prefix `macos-` the other should too -- or none should have it. > > Also, `-f` usually is used in conjunction with other options e.g. `-fmove-loop-invariants`. Which is probably the reason behind the capital letter `-F`. I'd suggest dropping the prefix, and maybe issuing a warning if it's used on an other platform. Otherwise we end up with `--macos-F` ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1981519472 From mcimadamore at openjdk.org Wed Mar 5 15:39:18 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 5 Mar 2025 15:39:18 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v4] In-Reply-To: References: Message-ID: On Wed, 5 Mar 2025 14:30:45 GMT, Nizar Benalla wrote: >> Also, `-f` usually is used in conjunction with other options e.g. `-fmove-loop-invariants`. Which is probably the reason behind the capital letter `-F`. > > I'd suggest dropping the prefix, and maybe issuing a warning if it's used on an other platform. Otherwise we end up with `--macos-F` I'm fine with that ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1981672156 From nbenalla at openjdk.org Wed Mar 5 15:57:41 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 5 Mar 2025 15:57:41 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v6] In-Reply-To: References: Message-ID: <9x1QbFoVL1f-FWDnrGJSwNiOzcocEgoS77sQvWJnqvg=.1056b7ae-7432-4627-8038-b67bb4e51f07@github.com> > 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: -search custom framework dirs -rename options ------------- Changes: - all: https://git.openjdk.org/jextract/pull/268/files - new: https://git.openjdk.org/jextract/pull/268/files/46b4a1d6..aa0ea679 Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=05 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=04-05 Stats: 36 lines in 4 files changed: 19 ins; 1 del; 16 mod Patch: https://git.openjdk.org/jextract/pull/268.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/268/head:pull/268 PR: https://git.openjdk.org/jextract/pull/268 From nbenalla at openjdk.org Wed Mar 5 16:03:08 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 5 Mar 2025 16:03:08 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v4] In-Reply-To: References: Message-ID: On Wed, 5 Mar 2025 12:42:56 GMT, Maurizio Cimadamore wrote: >> src/main/java/org/openjdk/jextract/JextractTool.java line 605: >> >>> 603: private String formatFrameworkPath(String optionString) { >>> 604: String publicPath = String.format("/System/Library/Frameworks/%1$s.framework/", optionString); >>> 605: String privatePath = String.format("/System/Library/PrivateFrameworks/%1$s.framework/", optionString); >> >> I think Maurizios comment still applies. AFAIU we need to pass the exact framework path to `dlopen`, so we need to manually search for the frameworks in this system location, and also in the locations specified through `-F`, and then load it from one of those locations. > > Yep -- it seems to me that public/private paths are _default_ framework paths. But user can add more paths to that list, using `-F`. Btw, one related question here is what is the expected priority of the search -- e.g. should we look into `-F` paths first, and then use public/private paths as fallbacks or the other way around? Thanks Jorn, I confused private and custom frameworks when I was writing this. I look at the `-F` paths first which include paths in `compile_flags.txt`, those passed using `-framework` and the MacOS SDK then private/public frameworks. ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1981716318 From jvernee at openjdk.org Wed Mar 5 16:26:27 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 5 Mar 2025 16:26:27 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v6] In-Reply-To: <9x1QbFoVL1f-FWDnrGJSwNiOzcocEgoS77sQvWJnqvg=.1056b7ae-7432-4627-8038-b67bb4e51f07@github.com> References: <9x1QbFoVL1f-FWDnrGJSwNiOzcocEgoS77sQvWJnqvg=.1056b7ae-7432-4627-8038-b67bb4e51f07@github.com> Message-ID: On Wed, 5 Mar 2025 15:57:41 GMT, Nizar Benalla 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: > > -search custom framework dirs > -rename options src/main/java/org/openjdk/jextract/JextractTool.java line 366: > 364: parser.accepts("--version", "help.version", false); > 365: parser.accepts("-framework", "help.mac.framework", true); > 366: parser.accepts("-F", "help.framework.library.path", true); I think these should be the other way around. `-F` specifies the search path, and `-framework` accepts the name of the framework you want to link against (e.g. `-framework OpenGL`). src/main/java/org/openjdk/jextract/JextractTool.java line 396: > 394: Files.lines(compileFlagsTxt).forEach(opt -> { > 395: builder.addClangArg(opt); > 396: frameworkDirs.add(opt.substring(2).trim()); Compile flags can also contain other flags, so we have to explicitly look for `-F` options here for this to work. But, I'd also be okay just ignoring the `-F` flags in `compile_flags`. We can tell people to use the builtin `-F`. src/main/java/org/openjdk/jextract/JextractTool.java line 459: > 457: optionSet.valuesOf("-framework").forEach( > 458: p -> { > 459: builder.addClangArg("-F" + p); See the mismatch here. Both should be `-F`. src/main/java/org/openjdk/jextract/JextractTool.java line 623: > 621: > 622: String publicPath = String.format("/System/Library/Frameworks/%1$s.framework/", optionString); > 623: String privatePath = String.format("/System/Library/PrivateFrameworks/%1$s.framework/", optionString); Also, shouldn't this default just use the result of `inferMacOSFrameworkPath`? ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1981746423 PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1981753440 PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1981755874 PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1981750743 From nbenalla at openjdk.org Wed Mar 5 17:04:23 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 5 Mar 2025 17:04:23 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v6] In-Reply-To: References: <9x1QbFoVL1f-FWDnrGJSwNiOzcocEgoS77sQvWJnqvg=.1056b7ae-7432-4627-8038-b67bb4e51f07@github.com> Message-ID: On Wed, 5 Mar 2025 16:19:37 GMT, Jorn Vernee wrote: >> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: >> >> -search custom framework dirs >> -rename options > > src/main/java/org/openjdk/jextract/JextractTool.java line 623: > >> 621: >> 622: String publicPath = String.format("/System/Library/Frameworks/%1$s.framework/", optionString); >> 623: String privatePath = String.format("/System/Library/PrivateFrameworks/%1$s.framework/", optionString); > > Also, shouldn't this default just use the result of `inferMacOSFrameworkPath`? Sure, note that the result of `inferMacOSFrameworkPath ` is checked before as it was added to `frameworkDirs`. The path would still be incorrect but maybe it's better than a malformed path. ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1981819319 From nbenalla at openjdk.org Wed Mar 5 17:38:49 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 5 Mar 2025 17:38:49 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v7] In-Reply-To: References: Message-ID: <_yP8csW14Wnq1RO8rtFR_xw0tulBUAbpxfONZLgBroc=.a3089786-df87-4aac-9ec8-bff98c134856@github.com> > 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: inverse -framework and -F ------------- Changes: - all: https://git.openjdk.org/jextract/pull/268/files - new: https://git.openjdk.org/jextract/pull/268/files/aa0ea679..dce35301 Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=06 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=05-06 Stats: 33 lines in 4 files changed: 4 ins; 12 del; 17 mod Patch: https://git.openjdk.org/jextract/pull/268.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/268/head:pull/268 PR: https://git.openjdk.org/jextract/pull/268 From nbenalla at openjdk.org Thu Mar 6 14:04:21 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 6 Mar 2025 14:04:21 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v6] In-Reply-To: References: <9x1QbFoVL1f-FWDnrGJSwNiOzcocEgoS77sQvWJnqvg=.1056b7ae-7432-4627-8038-b67bb4e51f07@github.com> Message-ID: On Wed, 5 Mar 2025 16:21:16 GMT, Jorn Vernee wrote: >> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: >> >> -search custom framework dirs >> -rename options > > src/main/java/org/openjdk/jextract/JextractTool.java line 396: > >> 394: Files.lines(compileFlagsTxt).forEach(opt -> { >> 395: builder.addClangArg(opt); >> 396: frameworkDirs.add(opt.substring(2).trim()); > > Compile flags can also contain other flags, so we have to explicitly look for `-F` options here for this to work. > > But, I'd also be okay just ignoring the `-F` flags in `compile_flags`. We can tell people to use the builtin `-F`. I chose to ignore the `-F` flags in `compile_flags`. The paths passed using the builtin `-F` will be checked first before public/private paths and the MacOs SDK, that way there are "good" defaults and it's simple enough for users to override them ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1983406571 From mcimadamore at openjdk.org Thu Mar 6 15:04:08 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 6 Mar 2025 15:04:08 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v7] In-Reply-To: <_yP8csW14Wnq1RO8rtFR_xw0tulBUAbpxfONZLgBroc=.a3089786-df87-4aac-9ec8-bff98c134856@github.com> References: <_yP8csW14Wnq1RO8rtFR_xw0tulBUAbpxfONZLgBroc=.a3089786-df87-4aac-9ec8-bff98c134856@github.com> Message-ID: On Wed, 5 Mar 2025 17:38:49 GMT, Nizar Benalla 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: > > inverse -framework and -F src/main/java/org/openjdk/jextract/JextractTool.java line 609: > 607: > 608: private String formatFrameworkPath(String optionString) { > 609: for (String dir : frameworkDirs) { It still feels like this code can be made more regular by keeping a list of framework paths in this class, then prepending new paths (the ones added with `-framework`) and then scanning the list and returning the first match. ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1983518830 From nbenalla at openjdk.org Fri Mar 7 15:38:43 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 7 Mar 2025 15:38:43 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v8] In-Reply-To: References: Message-ID: > 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: simplify formatFrameworkPath and rename it to be more accurate ------------- Changes: - all: https://git.openjdk.org/jextract/pull/268/files - new: https://git.openjdk.org/jextract/pull/268/files/dce35301..61e7f2c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=07 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=06-07 Stats: 42 lines in 1 file changed: 16 ins; 18 del; 8 mod Patch: https://git.openjdk.org/jextract/pull/268.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/268/head:pull/268 PR: https://git.openjdk.org/jextract/pull/268 From nbenalla at openjdk.org Fri Mar 7 15:41:17 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 7 Mar 2025 15:41:17 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v7] In-Reply-To: References: <_yP8csW14Wnq1RO8rtFR_xw0tulBUAbpxfONZLgBroc=.a3089786-df87-4aac-9ec8-bff98c134856@github.com> Message-ID: <8q-rCQu_uHYZYmq0AYq2r5Nxu8n4gsg-HUUQ4tkxDgY=.b3a7a27a-a631-4e71-bcd6-89f5547ce6d3@github.com> On Thu, 6 Mar 2025 15:01:35 GMT, Maurizio Cimadamore wrote: >> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: >> >> inverse -framework and -F > > src/main/java/org/openjdk/jextract/JextractTool.java line 609: > >> 607: >> 608: private String formatFrameworkPath(String optionString) { >> 609: for (String dir : frameworkDirs) { > > It still feels like this code can be made more regular by keeping a list of framework paths in this class, then prepending new paths (the ones added with `-framework`) and then scanning the list and returning the first match. I've made a small update to achieve this. Also moved the code the handle the `-F` options to be higher as we need to add those paths to the list before we can resolve the framework paths. (I missed this before) I've renamed some variables/methods to be more accurate, as the previous name was a bit misleading. ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1985279135 From nbenalla at openjdk.org Fri Mar 7 16:42:23 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 7 Mar 2025 16:42:23 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v9] In-Reply-To: References: Message-ID: <5urifc3dbX3KSKbtBOJKwql9UDoFwP489nQ9ZLbqOuo=.3734f96e-c873-491b-b550-ad2b2d9d7c55@github.com> > 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: error handling + assertion isn't necessary ------------- Changes: - all: https://git.openjdk.org/jextract/pull/268/files - new: https://git.openjdk.org/jextract/pull/268/files/61e7f2c6..1aa1af23 Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=08 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=07-08 Stats: 7 lines in 1 file changed: 3 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jextract/pull/268.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/268/head:pull/268 PR: https://git.openjdk.org/jextract/pull/268 From nbenalla at openjdk.org Fri Mar 7 16:49:26 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 7 Mar 2025 16:49:26 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v10] In-Reply-To: References: Message-ID: > 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: renaming variable to be more accurate ------------- Changes: - all: https://git.openjdk.org/jextract/pull/268/files - new: https://git.openjdk.org/jextract/pull/268/files/1aa1af23..da22de95 Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=09 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=08-09 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jextract/pull/268.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/268/head:pull/268 PR: https://git.openjdk.org/jextract/pull/268 From nbenalla at openjdk.org Fri Mar 7 16:49:26 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 7 Mar 2025 16:49:26 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v9] In-Reply-To: <5urifc3dbX3KSKbtBOJKwql9UDoFwP489nQ9ZLbqOuo=.3734f96e-c873-491b-b550-ad2b2d9d7c55@github.com> References: <5urifc3dbX3KSKbtBOJKwql9UDoFwP489nQ9ZLbqOuo=.3734f96e-c873-491b-b550-ad2b2d9d7c55@github.com> Message-ID: On Fri, 7 Mar 2025 16:42:23 GMT, Nizar Benalla 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: > > error handling + assertion isn't necessary If the framework path can't be resolved the user gets the following error, `error: invalid library specifier for -framework option: `. I made a small change to throw an exception rather than have a simple assert. ------------- PR Comment: https://git.openjdk.org/jextract/pull/268#issuecomment-2706928548 From mcimadamore at openjdk.org Fri Mar 7 18:05:11 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 7 Mar 2025 18:05:11 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v10] In-Reply-To: References: Message-ID: <3GI7drPoVzz2e1i1sXmdnh7_M8G0jvYKvhZfc0c8uD0=.f4419a4c-5329-4bc8-8585-3f3972a5e8a2@github.com> On Fri, 7 Mar 2025 16:49:26 GMT, Nizar Benalla 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: > > renaming variable to be more accurate src/main/java/org/openjdk/jextract/JextractTool.java line 539: > 537: for (String lib : optionSet.valuesOf("-" + optionString)) { > 538: try { > 539: lib = optionString.equals("framework") ? Is the argument of `framework` always a relative path? Or does macos also allow absolute paths to be used? In that case, should be check for something that starts with `/` ? ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1985476128 From mcimadamore at openjdk.org Fri Mar 7 18:08:06 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 7 Mar 2025 18:08:06 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v10] In-Reply-To: <3GI7drPoVzz2e1i1sXmdnh7_M8G0jvYKvhZfc0c8uD0=.f4419a4c-5329-4bc8-8585-3f3972a5e8a2@github.com> References: <3GI7drPoVzz2e1i1sXmdnh7_M8G0jvYKvhZfc0c8uD0=.f4419a4c-5329-4bc8-8585-3f3972a5e8a2@github.com> Message-ID: <2h_NY-rSe2xFHHuQ0f-O411Eu39V9CNJKLzb3iap-l4=.48d5a13f-5af7-4d5d-b750-9c191ec1330b@github.com> On Fri, 7 Mar 2025 18:02:25 GMT, Maurizio Cimadamore wrote: >> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: >> >> renaming variable to be more accurate > > src/main/java/org/openjdk/jextract/JextractTool.java line 539: > >> 537: for (String lib : optionSet.valuesOf("-" + optionString)) { >> 538: try { >> 539: lib = optionString.equals("framework") ? > > Is the argument of `framework` always a relative path? Or does macos also allow absolute paths to be used? In that case, should be check for something that starts with `/` ? gaaaah - got confused -- `-framework` is a framework name. In that case, the code is good (and better than before, thanks!). But the exception seems misleading. It should say something like `Cannot resolve/find framework `, rather than speaking about paths? ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1985479718 From nbenalla at openjdk.org Fri Mar 7 18:30:27 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 7 Mar 2025 18:30:27 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v11] In-Reply-To: References: Message-ID: > 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: improve error message ------------- Changes: - all: https://git.openjdk.org/jextract/pull/268/files - new: https://git.openjdk.org/jextract/pull/268/files/da22de95..09dfa8c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=10 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=09-10 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jextract/pull/268.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/268/head:pull/268 PR: https://git.openjdk.org/jextract/pull/268 From nbenalla at openjdk.org Fri Mar 7 18:30:28 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 7 Mar 2025 18:30:28 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v10] In-Reply-To: <2h_NY-rSe2xFHHuQ0f-O411Eu39V9CNJKLzb3iap-l4=.48d5a13f-5af7-4d5d-b750-9c191ec1330b@github.com> References: <3GI7drPoVzz2e1i1sXmdnh7_M8G0jvYKvhZfc0c8uD0=.f4419a4c-5329-4bc8-8585-3f3972a5e8a2@github.com> <2h_NY-rSe2xFHHuQ0f-O411Eu39V9CNJKLzb3iap-l4=.48d5a13f-5af7-4d5d-b750-9c191ec1330b@github.com> Message-ID: On Fri, 7 Mar 2025 18:05:58 GMT, Maurizio Cimadamore wrote: >> src/main/java/org/openjdk/jextract/JextractTool.java line 539: >> >>> 537: for (String lib : optionSet.valuesOf("-" + optionString)) { >>> 538: try { >>> 539: lib = optionString.equals("framework") ? >> >> Is the argument of `framework` always a relative path? Or does macos also allow absolute paths to be used? In that case, should be check for something that starts with `/` ? > > gaaaah - got confused -- `-framework` is a framework name. In that case, the code is good (and better than before, thanks!). But the exception seems misleading. It should say something like `Cannot resolve/find framework `, rather than speaking about paths? Updated the error message, the user should see `error: cannot find framework for -framework option: NAME` ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1985509842 From mcimadamore at openjdk.org Fri Mar 7 18:49:10 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 7 Mar 2025 18:49:10 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v11] In-Reply-To: References: Message-ID: On Fri, 7 Mar 2025 18:30:27 GMT, Nizar Benalla 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: > > improve error message src/main/resources/org/openjdk/jextract/impl/resources/Messages.properties line 29: > 27: not.a.file=not a file: {0} > 28: l.option.value.invalid=invalid library specifier for -l option: {0} > 29: framework.option.value.invalid=cannot find framework for -framework option: {0} I suggest to just say `Cannot find framework {0}`. Adding `for framework option` doesn't seem too useful? ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1985537043 From nbenalla at openjdk.org Fri Mar 7 19:43:45 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 7 Mar 2025 19:43:45 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v12] In-Reply-To: References: Message-ID: > 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: review feedback: improve error message ------------- Changes: - all: https://git.openjdk.org/jextract/pull/268/files - new: https://git.openjdk.org/jextract/pull/268/files/09dfa8c3..e4c2e55a Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=11 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jextract/pull/268.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/268/head:pull/268 PR: https://git.openjdk.org/jextract/pull/268 From nbenalla at openjdk.org Fri Mar 7 19:43:47 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 7 Mar 2025 19:43:47 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v11] In-Reply-To: References: Message-ID: On Fri, 7 Mar 2025 18:46:14 GMT, Maurizio Cimadamore wrote: >> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: >> >> improve error message > > src/main/resources/org/openjdk/jextract/impl/resources/Messages.properties line 29: > >> 27: not.a.file=not a file: {0} >> 28: l.option.value.invalid=invalid library specifier for -l option: {0} >> 29: framework.option.value.invalid=cannot find framework for -framework option: {0} > > I suggest to just say `Cannot find framework {0}`. Adding `for framework option` doesn't seem too useful? Sure, I admit it's redundant information ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1985594217 From mcimadamore at openjdk.org Fri Mar 7 22:08:08 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 7 Mar 2025 22:08:08 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v12] In-Reply-To: References: Message-ID: <0Mv6_EwAV3NBmMhvhQnrGI2b6Yoo3DXsquc55rwTuNc=.8e6a360a-9a1f-4733-b2d2-ab20932eafe8@github.com> On Fri, 7 Mar 2025 19:43:45 GMT, Nizar Benalla 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: > > review feedback: improve error message Looks good - thanks! ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jextract/pull/268#pullrequestreview-2668481600 From jvernee at openjdk.org Mon Mar 10 10:49:07 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 10 Mar 2025 10:49:07 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v12] In-Reply-To: References: Message-ID: On Fri, 7 Mar 2025 19:43:45 GMT, Nizar Benalla 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: > > review feedback: improve error message It would be nice if some tests could be added for this, but I expect it's tricky since we don't know if there's any frameworks or SDKs installed on the target system. src/main/java/org/openjdk/jextract/JextractTool.java line 371: > 369: parser.accepts("--version", "help.version", false); > 370: parser.accepts("-F", "help.mac.framework", true); > 371: parser.accepts("-framework", "help.framework.library.path", true); e.g. something simple like: Suggestion: if (isMacOSX) { parser.accepts("-F", "help.mac.framework", true); parser.accepts("-framework", "help.framework.library.path", true); } src/main/java/org/openjdk/jextract/JextractTool.java line 456: > 454: paths.forEach(p -> builder.addClangArg("-F" + p)); > 455: frameworkPaths.addAll(0, paths); > 456: } My only concern left is what now happens on non-mac platforms when `-F` or `-framework` is used. I suppose clang might error out on the flag in the case of `-F`, not sure what happens for `-framework`. I think these options should perhaps be disabled on platforms besides mac, since they are only intended to be used there. ------------- PR Review: https://git.openjdk.org/jextract/pull/268#pullrequestreview-2670506439 PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1987037128 PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1987035427 From mcimadamore at openjdk.org Mon Mar 10 11:03:17 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 10 Mar 2025 11:03:17 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v12] In-Reply-To: References: Message-ID: On Fri, 7 Mar 2025 19:43:45 GMT, Nizar Benalla 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: > > review feedback: improve error message Also forgot about this: https://github.com/openjdk/jextract/blob/master/samples/opengl/compile_flags.txt The OpenGL example has a compile_flags to set the framework option. I think that should be dropped and the new jextract option should be mentioned in that example ------------- PR Comment: https://git.openjdk.org/jextract/pull/268#issuecomment-2710196784 From nbenalla at openjdk.org Mon Mar 10 11:34:07 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 10 Mar 2025 11:34:07 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v12] In-Reply-To: References: Message-ID: On Mon, 10 Mar 2025 10:43:09 GMT, Jorn Vernee wrote: >> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: >> >> review feedback: improve error message > > src/main/java/org/openjdk/jextract/JextractTool.java line 456: > >> 454: paths.forEach(p -> builder.addClangArg("-F" + p)); >> 455: frameworkPaths.addAll(0, paths); >> 456: } > > My only concern left is what now happens on non-mac platforms when `-F` or `-framework` is used. I suppose clang might error out on the flag in the case of `-F`, not sure what happens for `-framework`. > > I think these options should perhaps be disabled on platforms besides mac, since they are only intended to be used there. @mcimadamore What do you think about emitting errors on non-mac platforms? ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1987106905 From mcimadamore at openjdk.org Mon Mar 10 11:37:08 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 10 Mar 2025 11:37:08 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v12] In-Reply-To: References: Message-ID: On Mon, 10 Mar 2025 11:00:37 GMT, Maurizio Cimadamore wrote: > Also forgot about this: https://github.com/openjdk/jextract/blob/master/samples/opengl/compile_flags.txt > > The OpenGL example has a compile_flags to set the framework option. I think that should be dropped and the new jextract option should be mentioned in that example Apologies -- I've missed the changes to the example -- this looks good already ------------- PR Comment: https://git.openjdk.org/jextract/pull/268#issuecomment-2710283997 From mcimadamore at openjdk.org Mon Mar 10 11:40:07 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 10 Mar 2025 11:40:07 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v12] In-Reply-To: References: Message-ID: On Mon, 10 Mar 2025 11:31:09 GMT, Nizar Benalla wrote: >> src/main/java/org/openjdk/jextract/JextractTool.java line 456: >> >>> 454: paths.forEach(p -> builder.addClangArg("-F" + p)); >>> 455: frameworkPaths.addAll(0, paths); >>> 456: } >> >> My only concern left is what now happens on non-mac platforms when `-F` or `-framework` is used. I suppose clang might error out on the flag in the case of `-F`, not sure what happens for `-framework`. >> >> I think these options should perhaps be disabled on platforms besides mac, since they are only intended to be used there. > > @mcimadamore What do you think about emitting errors on non-mac platforms? I think we should either: * not recognize the options when not on macos * recognize them, but turn them into no-op (e.g. do nothing if not on macos) If we recognize them AND try to act on them (e.g. by setting `-F` on the underlying `clang` process, I could see issue with that approach, as @JornVernee mentions) ------------- PR Review Comment: https://git.openjdk.org/jextract/pull/268#discussion_r1987115789 From nbenalla at openjdk.org Mon Mar 10 12:22:59 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 10 Mar 2025 12:22:59 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v13] In-Reply-To: References: Message-ID: <5hR070M-_JZT4h0XJhOrBur1Am6921vjmzd-vTHMeDc=.97e08638-b4ef-45e3-bedd-da199e01a1ab@github.com> > 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: review feedback: -F and -framework options should be recognized on non-mac platforms ------------- Changes: - all: https://git.openjdk.org/jextract/pull/268/files - new: https://git.openjdk.org/jextract/pull/268/files/e4c2e55a..7e628e81 Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=12 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=268&range=11-12 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jextract/pull/268.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/268/head:pull/268 PR: https://git.openjdk.org/jextract/pull/268 From jvernee at openjdk.org Mon Mar 10 12:31:19 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 10 Mar 2025 12:31:19 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v13] In-Reply-To: <5hR070M-_JZT4h0XJhOrBur1Am6921vjmzd-vTHMeDc=.97e08638-b4ef-45e3-bedd-da199e01a1ab@github.com> References: <5hR070M-_JZT4h0XJhOrBur1Am6921vjmzd-vTHMeDc=.97e08638-b4ef-45e3-bedd-da199e01a1ab@github.com> Message-ID: On Mon, 10 Mar 2025 12:22:59 GMT, Nizar Benalla 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: > > review feedback: -F and -framework options should be recognized on non-mac platforms Latest version looks good ------------- Marked as reviewed by jvernee (Committer). PR Review: https://git.openjdk.org/jextract/pull/268#pullrequestreview-2670781367 From nbenalla at openjdk.org Mon Mar 10 12:35:07 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 10 Mar 2025 12:35:07 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v13] In-Reply-To: <5hR070M-_JZT4h0XJhOrBur1Am6921vjmzd-vTHMeDc=.97e08638-b4ef-45e3-bedd-da199e01a1ab@github.com> References: <5hR070M-_JZT4h0XJhOrBur1Am6921vjmzd-vTHMeDc=.97e08638-b4ef-45e3-bedd-da199e01a1ab@github.com> Message-ID: On Mon, 10 Mar 2025 12:22:59 GMT, Nizar Benalla 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: > > review feedback: -F and -framework options should be recognized on non-mac platforms Thanks for all the reviews. ------------- PR Comment: https://git.openjdk.org/jextract/pull/268#issuecomment-2710429623 From duke at openjdk.org Mon Mar 10 12:35:07 2025 From: duke at openjdk.org (duke) Date: Mon, 10 Mar 2025 12:35:07 GMT Subject: RFR: 7903731: Jextract should support macOS frameworks [v13] In-Reply-To: <5hR070M-_JZT4h0XJhOrBur1Am6921vjmzd-vTHMeDc=.97e08638-b4ef-45e3-bedd-da199e01a1ab@github.com> References: <5hR070M-_JZT4h0XJhOrBur1Am6921vjmzd-vTHMeDc=.97e08638-b4ef-45e3-bedd-da199e01a1ab@github.com> Message-ID: On Mon, 10 Mar 2025 12:22:59 GMT, Nizar Benalla 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: > > review feedback: -F and -framework options should be recognized on non-mac platforms @nizarbenalla Your change (at version 7e628e8156d0880c9ffff10d4589b21acd608387) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jextract/pull/268#issuecomment-2710432344 From duke at openjdk.org Tue Mar 11 02:16:04 2025 From: duke at openjdk.org (duke) Date: Tue, 11 Mar 2025 02:16:04 GMT Subject: Withdrawn: Gradle 8.11.1 update cleanups In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 18:14:03 GMT, Jorn Vernee wrote: > Some things were missed as part of: https://github.com/openjdk/jextract/pull/264 > > - The action to validate the gradle wrapper accidentally uses a deprecated version > - The readme was not updated. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jextract/pull/272 From liach at openjdk.org Tue Mar 11 21:36:13 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 11 Mar 2025 21:36:13 GMT Subject: RFR: Gradle 8.11.1 update cleanups [v2] In-Reply-To: References: Message-ID: On Wed, 5 Mar 2025 10:46:37 GMT, Jorn Vernee wrote: >> Some things were missed as part of: https://github.com/openjdk/jextract/pull/264 >> >> - The action to validate the gradle wrapper accidentally uses a deprecated version >> - The readme was not updated. > > Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into GradleCleanup > - update readme > - use non-deprecated action to validate gradle wrapper Looks good. Feel free to merge. ------------- PR Comment: https://git.openjdk.org/jextract/pull/272#issuecomment-2715756340 From jvernee at openjdk.org Thu Mar 13 11:41:12 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 13 Mar 2025 11:41:12 GMT Subject: Integrated: Gradle 8.11.1 update cleanups In-Reply-To: References: Message-ID: On Mon, 13 Jan 2025 18:14:03 GMT, Jorn Vernee wrote: > Some things were missed as part of: https://github.com/openjdk/jextract/pull/264 > > - The action to validate the gradle wrapper accidentally uses a deprecated version > - The readme was not updated. This pull request has now been integrated. Changeset: f784e9c1 Author: Jorn Vernee URL: https://git.openjdk.org/jextract/commit/f784e9c1698b942d2a912ddac068468775ff0f55 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Gradle 8.11.1 update cleanups ------------- PR: https://git.openjdk.org/jextract/pull/272 From duke at openjdk.org Wed Mar 19 00:49:20 2025 From: duke at openjdk.org (duke) Date: Wed, 19 Mar 2025 00:49:20 GMT Subject: Withdrawn: 7903928: update build.gradle to use JDK 23 In-Reply-To: References: Message-ID: On Thu, 9 Jan 2025 06:54:02 GMT, Athijegannathan Sundararajan wrote: > We've updated native makefile to use JDK 23 ( > https://github.com/openjdk/jextract/commit/0b89a462146940a2ec90e34eeb5df3d46d8980d2 ) > > While build.gradle works & expects jdk 23, it still refers to JDK var as "jdk22_home" and passes --release to be 22. Also jextract version is "22". This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jextract/pull/271 From lain at null.net Wed Mar 26 02:27:54 2025 From: lain at null.net (Lain Lain) Date: Wed, 26 Mar 2025 03:27:54 +0100 Subject: ffmbindings manual bindings to C++ In-Reply-To: References: <1c827663-29fe-465f-9db3-85005da3ce91@oracle.com> Message-ID: Hi all, We have published new bindings, this time to Open3D C++ library: Source code: https://bitbucket.org/ffmbindings/ffmbindings-open3d Documentation: https://ffmbindings.onrender.com/javadoc/ffmbindings.open3d/index.html Point clouds processing is important in many areas, including robotics. There are very efficient C++ libraries to work with point clouds, for example: Open3D PCL These libraries in point clouds processing are as popular as OpenCV in computer vision. However, unlike OpenCV, none of these point cloud libraries offer official Java bindings, and moreover, they don't have C bindings either (which means that it's not possible to produce FFM bindings to them with jextract). ffmbindings.open3d provides Java FFM bindings to Open3D. Open3D as a library features many C++ techniques like templates/vectors/shared_ptr/inheritance/eigen. ffmbindings.open3d uses all of them with FFM API Thank you, > 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[https://ffmbindings.onrender.com] > ? > Any feedback are welcome. > ? > Thank you, From nbenalla at openjdk.org Thu Mar 27 05:47:11 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 27 Mar 2025 05:47:11 GMT Subject: RFR: 7903933: Move sharable items from different generations to a common file [v3] In-Reply-To: References: Message-ID: > 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 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 five additional commits since the last revision: - add new option to create a sharable utility class cleanup: longer cmd option `framework` should use -- rather than - small other cleanups - Merge branch 'master' into shareable-items - Revert all changes - starting over from scratch - replace hardcoded strings I missed - move sharable items to a common class ------------- Changes: - all: https://git.openjdk.org/jextract/pull/278/files - new: https://git.openjdk.org/jextract/pull/278/files/fa41fe8b..736ccfba Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=278&range=02 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=278&range=01-02 Stats: 704 lines in 32 files changed: 332 ins; 256 del; 116 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 Thu Mar 27 05:55:09 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 27 Mar 2025 05:55:09 GMT Subject: RFR: 7903933: Move sharable items from different generations to a common file [v3] In-Reply-To: References: Message-ID: <89uH1fbmAtfSrYn-qeYoWlBwqa7k-3fKYIkBJJz_CCs=.d3517ecb-4afe-49f5-9ced-e4186ec2e662@github.com> On Thu, 27 Mar 2025 05:47:11 GMT, Nizar Benalla wrote: >> 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 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 five additional commits since the last revision: > > - add new option to create a sharable utility class > > cleanup: longer cmd option `framework` should use -- rather than - > > small other cleanups > - Merge branch 'master' into shareable-items > - Revert all changes - starting over from scratch > - replace hardcoded strings I missed > - move sharable items to a common class I wasn't happy with the previous approach/implementation and started over from scratch, also did some small cleanup (the newly added option for framworks should use `--` rather than `-`). Shared items from multiple generation will only be moved to a class if the user specifies the `--sharable-items` option, with the class name of his choosing and the main header file extends that class. This will be helpful for project that need to run jextract on multiple headers, especially if those headers are large. ------------- PR Comment: https://git.openjdk.org/jextract/pull/278#issuecomment-2756779244 From nbenalla at openjdk.org Thu Mar 27 05:55:08 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 27 Mar 2025 05:55:08 GMT Subject: RFR: 7903933: Move sharable items from different generations to a common file [v4] In-Reply-To: References: Message-ID: > 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 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 shareable-items - add new option to create a sharable utility class cleanup: longer cmd option `framework` should use -- rather than - small other cleanups - Merge branch 'master' into shareable-items - Revert all changes - starting over from scratch - replace hardcoded strings I missed - move sharable items to a common class ------------- Changes: - all: https://git.openjdk.org/jextract/pull/278/files - new: https://git.openjdk.org/jextract/pull/278/files/736ccfba..69d46473 Webrevs: - full: https://webrevs.openjdk.org/?repo=jextract&pr=278&range=03 - incr: https://webrevs.openjdk.org/?repo=jextract&pr=278&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 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 mcimadamore at openjdk.org Thu Mar 27 10:36:38 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 27 Mar 2025 10:36:38 GMT Subject: RFR: 7903933: Move sharable items from different generations to a common file [v4] In-Reply-To: References: Message-ID: <5x3iMoFCYI5mduzOrn7e9E5Jbz7YL7DjxWlxxJlmpmM=.9237732e-c328-4651-b0cd-b35f401db1c3@github.com> On Thu, 27 Mar 2025 05:55:08 GMT, Nizar Benalla wrote: >> 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 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 shareable-items > - add new option to create a sharable utility class > > cleanup: longer cmd option `framework` should use -- rather than - > > small other cleanups > - Merge branch 'master' into shareable-items > - Revert all changes - starting over from scratch > - replace hardcoded strings I missed > - move sharable items to a common class Adding an option to move shared items in a separate class feels like taking a shortcut. Let's look what's inside this bag of shared items (it used to be much bigger, so good news there): 1. library arena 2. trace downcall support 3. alignment method 4. findOrThrow 5. upcallHandle 6. primitive layout constants I believe (1) should probably not belong in a separate class from the headers. The way I see it is that it should belong where the library lookups belongs to. Even if you run multiple extractions it is less clear to me as to whether there should be a single lifetime for all the different libraries or not (and, eventually, we want aspects such as this to be customizable via subclassing). (2) seems a very useful debug option, and I think we should think about making it more official -- for instance with a linker option. (3) is a general purpose method that would make sense to feature in the main MemoryLayout API. (4) seems to be superseded by a similar method that was added in Java 23: https://docs.oracle.com/en/java/javase/23/docs//api/java.base/java/lang/foreign/SymbolLookup.html#findOrThrow(java.lang.String) (5) seems like it could be inlined in the functional interface classes (it's just an helper to allow clients to create an upcall stub w/o the need to do a MethodHandle lookup -- which needs a try/catch). Then there's (6). The first reaction I got was: well, whether primitive layouts should be emitted or not seems like another filtering decision (e.g. let's add some options to filter these out). Except this would not work -- it's not just about filtering -- it's also about telling every other file where to find the layouts for such primitive types. If they are defined somewhere else, then jextract need to know _where_ to find them (e.g. if they are referenced by some other layout jextract is building). Which seems a similar problem as the one this PR is trying to solve anyway. Stepping back -- I think if we look back, jetxract used to generate a RuntimeHelper class, and then everything else. While we moved away from that generation scheme (now we just emit header classes), the shared functionalities are still there. Perhaps a move in a good direction would be to: * put all the shared functionalities in the root of the header hierarchy -- and _don't put anything else in there_ * this means that there will always be at least two header classes generated `foo_f` and `foo_h$0`, where `foo_h extends foo_h$0` and all the shared symbols are in `foo_h$0`. * add an option to override the name of that root header class This is similar, in spirit, to what you have here, but with the advantage that there's only one generation scheme, not two -- e.g. the superclass with the shared symbol is _always_ there -- only sometimes it can have a different name (because the user said so). Whether we want that default superclass name to be `foo_h$0`, or maybe something more explicit like `foo_h_shared`, I'm open to suggestions. But I do think that we should try and make that shared class as small as possible -- most of the functionality there seems like it could belong in the main FFM API, and it would provide value even for clients not running on top of jextract. ------------- PR Comment: https://git.openjdk.org/jextract/pull/278#issuecomment-2757539685 From mcimadamore at openjdk.org Thu Mar 27 10:39:23 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 27 Mar 2025 10:39:23 GMT Subject: RFR: 7903933: Move sharable items from different generations to a common file [v4] In-Reply-To: <5x3iMoFCYI5mduzOrn7e9E5Jbz7YL7DjxWlxxJlmpmM=.9237732e-c328-4651-b0cd-b35f401db1c3@github.com> References: <5x3iMoFCYI5mduzOrn7e9E5Jbz7YL7DjxWlxxJlmpmM=.9237732e-c328-4651-b0cd-b35f401db1c3@github.com> Message-ID: On Thu, 27 Mar 2025 10:33:26 GMT, Maurizio Cimadamore wrote: > Then there's (6). The first reaction I got was: well, whether primitive layouts should be emitted or not seems like another filtering decision (e.g. let's add some options to filter these out). Except this would not work -- it's not just about filtering -- it's also about telling every other file where to find the layouts for such primitive types. If they are defined somewhere else, then jextract need to know _where_ to find them (e.g. if they are referenced by some other layout jextract is building). Which seems a similar problem as the one this PR is trying to solve anyway. Note/history: while tempting, we can't really put (6) inside the main FFM API. We have thought about this for a long time -- the issue is that the types of the primitive layouts is not guaranteed to be stable. E.g. `C_LONG` might be either a `ValueLayout.OfLong` or a `ValueLayout.OfInt`, depending on the platforms. Other layouts, such as `C_LONG_DOUBLE` might only be available on some platforms and not others. This is why, long ago, we decided that the main FFM API should not concern with providing layout constants for C types -- as the set of such constant is not stable. Instead, such primitive C layouts can be "discovered" using the `Linker::canonicalLayouts` API. ------------- PR Comment: https://git.openjdk.org/jextract/pull/278#issuecomment-2757548082 From mcimadamore at openjdk.org Thu Mar 27 10:47:32 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 27 Mar 2025 10:47:32 GMT Subject: RFR: 7903933: Move sharable items from different generations to a common file [v4] In-Reply-To: References: <5x3iMoFCYI5mduzOrn7e9E5Jbz7YL7DjxWlxxJlmpmM=.9237732e-c328-4651-b0cd-b35f401db1c3@github.com> Message-ID: On Thu, 27 Mar 2025 10:36:29 GMT, Maurizio Cimadamore wrote: > Then there's (6). The first reaction I got was: well, whether primitive layouts should be emitted or not seems like another filtering decision (e.g. let's add some options to filter these out). Except this would not work -- it's not just about filtering -- it's also about telling every other file where to find the layouts for such primitive types. If they are defined somewhere else, then jextract need to know _where_ to find them (e.g. if they are referenced by some other layout jextract is building). Which seems a similar problem as the one this PR is trying to solve anyway. Also on this topic: for now we're mostly concerned about different extractions not repeating the code for primitive layouts and helper functions. This feels more like a "tip of the iceberg" kind of situation. For instance, you might have two libraries A and B, which both include the header of some third library C. Maybe you want to extract C separately, and then extract A and B so that they somehow magically point at the extracted bindings for C. Now sharing would be not just about primitive types, but about functions, structs and much more. At the same time, going down this path can be very complex: A and B might pull in slightly different versions of C, or use some `#define` macro directives which would alter the shape of the generated bindings in C. In which case reusing the same bindings for C would be more difficult. So, hidden somewhere in here there's a theme of: how do we move jextract to go from a per-extraction set of bindings to a multi-extraction friendly model. And going down this path will likely, I think, result in opening a big and complicated can of worms. I'm not saying we'll never get there -- but there's a limit with what we can express with simple command line options. ------------- PR Comment: https://git.openjdk.org/jextract/pull/278#issuecomment-2757571433 From jvernee at openjdk.org Thu Mar 27 14:52:22 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 27 Mar 2025 14:52:22 GMT Subject: RFR: 7903933: Move sharable items from different generations to a common file [v4] In-Reply-To: <5x3iMoFCYI5mduzOrn7e9E5Jbz7YL7DjxWlxxJlmpmM=.9237732e-c328-4651-b0cd-b35f401db1c3@github.com> References: <5x3iMoFCYI5mduzOrn7e9E5Jbz7YL7DjxWlxxJlmpmM=.9237732e-c328-4651-b0cd-b35f401db1c3@github.com> Message-ID: On Thu, 27 Mar 2025 10:33:26 GMT, Maurizio Cimadamore wrote: > this means that there will always be at least two header classes generated foo_f and foo_h$0, where foo_h extends foo_h$0 and all the shared symbols are in foo_h$0. Should we just give the base header a common name then, so that if you generate multiple times, you get sharing automatically? Maybe it could be named something like `Builtins`. ------------- PR Comment: https://git.openjdk.org/jextract/pull/278#issuecomment-2758351554 From mcimadamore at openjdk.org Thu Mar 27 15:06:28 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 27 Mar 2025 15:06:28 GMT Subject: RFR: 7903933: Move sharable items from different generations to a common file [v4] In-Reply-To: References: <5x3iMoFCYI5mduzOrn7e9E5Jbz7YL7DjxWlxxJlmpmM=.9237732e-c328-4651-b0cd-b35f401db1c3@github.com> Message-ID: <-NISHKP1IUMkE6YN1pxHC1X1VO22HuzoDNqs9TC8BNI=.9fd3bb7c-87a4-430f-bbaf-22076a6b8c29@github.com> On Thu, 27 Mar 2025 14:49:36 GMT, Jorn Vernee wrote: > > this means that there will always be at least two header classes generated foo_f and foo_h$0, where foo_h extends foo_h$0 and all the shared symbols are in foo_h$0. > > Should we just give the base header a common name then, so that if you generate multiple times, you get sharing automatically? Maybe it could be named something like `Builtins`. Yes, see > This is similar, in spirit, to what you have here, but with the advantage that there's only one generation scheme, not two -- e.g. the superclass with the shared symbol is always there -- only sometimes it can have a different name (because the user said so). Whether we want that default superclass name to be foo_h$0, or maybe something more explicit like foo_h_shared, I'm open to suggestions. ------------- PR Comment: https://git.openjdk.org/jextract/pull/278#issuecomment-2758398120 From nbenalla at openjdk.org Thu Mar 27 16:40:27 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 27 Mar 2025 16:40:27 GMT Subject: RFR: 7903933: Move sharable items from different generations to a common file [v4] In-Reply-To: References: Message-ID: On Thu, 27 Mar 2025 05:55:08 GMT, Nizar Benalla wrote: >> 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 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 shareable-items > - add new option to create a sharable utility class > > cleanup: longer cmd option `framework` should use -- rather than - > > small other cleanups > - Merge branch 'master' into shareable-items > - Revert all changes - starting over from scratch > - replace hardcoded strings I missed > - move sharable items to a common class > (4) findOrThrow > (4) seems to be superseded by a similar method that was added in Java 23: https://docs.oracle.com/en/java/javase/23/docs//api/java.base/java/lang/foreign/SymbolLookup.html#findOrThrow(java.lang.String) I meant to remove this when targeting jdk 23, it seems I left it by mistake. I will remove it to reduce the number of shared items we're dealing with. ------------- PR Comment: https://git.openjdk.org/jextract/pull/278#issuecomment-2758689477 From nbenalla at openjdk.org Fri Mar 28 14:20:25 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 28 Mar 2025 14:20:25 GMT Subject: RFR: 7903984: Inline upcallHandle method to reduce shared code across multiple generations Message-ID: Please review this patch to inline the upcallHandle method, reducing the amount of shared items across multiple jextract generations. TIA ------------- Commit messages: - remove whitespace - inline method Changes: https://git.openjdk.org/jextract/pull/279/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=279&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903984 Stats: 18 lines in 2 files changed: 8 ins; 8 del; 2 mod Patch: https://git.openjdk.org/jextract/pull/279.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/279/head:pull/279 PR: https://git.openjdk.org/jextract/pull/279 From nbenalla at openjdk.org Fri Mar 28 14:25:42 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 28 Mar 2025 14:25:42 GMT Subject: RFR: 7903983: Remove redundant findOrThrow method Message-ID: `SymbolLookup::FindOrThrow` was introduced in JDK 23, making this method in the generated code redundant: static MemorySegment findOrThrow(String symbol) { return SYMBOL_LOOKUP.findOrThrow(symbol); } The generated method should have been dropped in https://github.com/openjdk/jextract/commit/a53f5c05e3ee2cca057cadb78b2e381c39f943d7 but I didn't cleanup all uses of it. A small additional cleanup in PR is that the newly added option for framworks now uses `--` rather than `-` TIA ------------- Commit messages: - remove rendundant method - longer cmd option should use -- rather than - Changes: https://git.openjdk.org/jextract/pull/280/files Webrev: https://webrevs.openjdk.org/?repo=jextract&pr=280&range=00 Issue: https://bugs.openjdk.org/browse/CODETOOLS-7903983 Stats: 27 lines in 5 files changed: 3 ins; 4 del; 20 mod Patch: https://git.openjdk.org/jextract/pull/280.diff Fetch: git fetch https://git.openjdk.org/jextract.git pull/280/head:pull/280 PR: https://git.openjdk.org/jextract/pull/280 From mcimadamore at openjdk.org Fri Mar 28 17:52:50 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Mar 2025 17:52:50 GMT Subject: RFR: 7903983: Remove redundant findOrThrow method In-Reply-To: References: Message-ID: On Fri, 28 Mar 2025 14:11:26 GMT, Nizar Benalla wrote: > `SymbolLookup::FindOrThrow` was introduced in JDK 23, making this method in the generated code redundant: > > static MemorySegment findOrThrow(String symbol) { > return SYMBOL_LOOKUP.findOrThrow(symbol); > } > > The generated method should have been dropped in https://github.com/openjdk/jextract/commit/a53f5c05e3ee2cca057cadb78b2e381c39f943d7 but I didn't cleanup all uses of it. > > A small additional cleanup in PR is that the newly added option for framworks now uses `--` rather than `-` > > Edit: all tests pass in CI on all platforms, GitHub failure is unrelated > > TIA Looks good! ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jextract/pull/280#pullrequestreview-2726282132 From mcimadamore at openjdk.org Fri Mar 28 18:11:20 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 28 Mar 2025 18:11:20 GMT Subject: RFR: 7903984: Inline upcallHandle method to reduce shared code across multiple generations In-Reply-To: References: Message-ID: On Fri, 28 Mar 2025 14:05:23 GMT, Nizar Benalla wrote: > Please review this patch to inline the upcallHandle method, reducing the amount of shared items across multiple jextract generations. > > Edit: all tests pass in CI, GitHub failure is unrelated > > TIA Looks good. Let's also hear from @JornVernee (when looking at some generated code I also noted that the functional interface code already has a try/catch block in the `invoke` method). I guess the unfortunate issue here is that the use is from a static initializer - which means we either need to put the logic in a method (as you have done) or use a static initializer. So we pay a bit more than just for the single try/catch block. One thing I noticed is that `ConstantBootstraps` has bootstraps to make field var handles (static and non-static) as well as array element var handles. I wonder if we should double down on those and add a way to create direct method handles too... these methods don't throw checked exception, so they are more amenable to generated code like this. ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jextract/pull/279#pullrequestreview-2726320459 From jextract at xpple.dev Fri Mar 28 21:53:03 2025 From: jextract at xpple.dev (jextract at xpple.dev) Date: Fri, 28 Mar 2025 22:53:03 +0100 Subject: Bindings crash on Windows where they would not before Message-ID: <460893d85393d128b451150c27f4a510@xpple.dev> Hello, Firstly, thanks to the people behind this tool, I really like it. I have used it for both C and Rust libraries with great success. Unfortunately though, it seems commit [1] from PR [2] and relevant issue [3] caused bindings to generate that crash on Windows, where they before would not. I let GitHub Actions generate my bindings on an Ubuntu runner, where the size of the type `long` is `64` bits. On Windows however, the size of this type is `32` bits (thank Microsoft for that...). This means that on Windows, the bindings crash with the message `java.lang.ClassCastException: class jdk.internal.foreign.layout.ValueLayouts$OfIntImpl cannot be cast to class java.lang.foreign.ValueLayout$OfLong (jdk.internal.foreign.layout.ValueLayouts$OfIntImpl and java.lang.foreign.ValueLayout$OfLong are in module java.base of loader 'bootstrap')`. Before the `long` type was of _fixed_ size (regardless of the actual size), preventing a mismatch. While I know platform agnosticy is not a specific goal of jextract, this seems easy enough to provide a fix for. For instance the platform check could be done at runtime. In the meantime, what would your recommended fix be for my issue? Kind regards, Frederik van der Els [1] https://github.com/openjdk/jextract/commit/1c614f31fac9e6309e8d3498a128ac9484348c85 [2] https://github.com/openjdk/jextract/pull/269 [3] https://bugs.openjdk.org/browse/CODETOOLS-7903923 From maurizio.cimadamore at oracle.com Mon Mar 31 09:02:45 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 31 Mar 2025 10:02:45 +0100 Subject: Bindings crash on Windows where they would not before In-Reply-To: <460893d85393d128b451150c27f4a510@xpple.dev> References: <460893d85393d128b451150c27f4a510@xpple.dev> Message-ID: Hi, thanks for the report. I think the fix should still take into account for platform mismatches. Note that we now have a shared section, containing constants? for all platforms) and a follow up sections where we initialize platform-specific constants. The shared section only contains LONG_LONG, which is always 64 bits, even in Windows. The followup section contains LONG, which is 32bit/OfInt on Windows, and 64bit/OfLong elsewhere. What the follow up section does is determined by `TypeImpl.IS_WINDOWS`, which is defned here: https://github.com/openjdk/jextract/blob/master/src/main/java/org/openjdk/jextract/impl/TypeImpl.java#L45C1-L45C98 So, on Windows the right thing should happen. Maybe the problem is that you are trying to generate Windows bindings from a Linux machine? While the code used to work differently (e.g. no class cast exception), the bindings might behave unpredictably on Windows. It probably just happened that you never worked with libraries using `long` (which, for the portability issues you noted, is often avoided). If you have e.g. a struct containing a long field, the size and offsets of that struct would be completely bogus, so I would not recommend to use jextract in that cross-platform way -- it is not designed to work that way. The new error message points this out a little earlier (before something worse occurs). > For instance the platform check could be done at runtime. Yes, but at the end of the day we have to assign either a `OfLong` field, or a `OfLongLong` field. And we can't change the type of the field at runtime. Which means the type of the field is picked at extraction time (this was also the case before the fix), and at runtime we cast whatever `canonicalLayout` returns to the expected type (which throws if there is a mismatch). Perhaps, a slightly more lenient way to handle this would be to just leave the layouts to `null` if there's a mismatch (instead of throwing). This means that bindings only using "portable" layouts would still work. But, while this might fix your issue, I'm not 100% sure that would be much better in the general case. Maurizio From jorn.vernee at oracle.com Mon Mar 31 11:11:13 2025 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Mon, 31 Mar 2025 13:11:13 +0200 Subject: Bindings crash on Windows where they would not before In-Reply-To: References: <460893d85393d128b451150c27f4a510@xpple.dev> Message-ID: > It probably just happened that you never worked with libraries using `long` I think this is probably the case as well. As a workaround, you could try deleting the layout for `C_LONG` in the generated bindings. If the library is indeed portal enough, there should be no compilation errors. Jorn On 31-3-2025 11:02, Maurizio Cimadamore wrote: > Hi, > thanks for the report. > > I think the fix should still take into account for platform > mismatches. Note that we now have a shared section, containing > constants? for all platforms) and a follow up sections where we > initialize platform-specific constants. > > The shared section only contains LONG_LONG, which is always 64 bits, > even in Windows. > > The followup section contains LONG, which is 32bit/OfInt on Windows, > and 64bit/OfLong elsewhere. What the follow up section does is > determined by `TypeImpl.IS_WINDOWS`, which is defned here: > > https://github.com/openjdk/jextract/blob/master/src/main/java/org/openjdk/jextract/impl/TypeImpl.java#L45C1-L45C98 > > > So, on Windows the right thing should happen. > > Maybe the problem is that you are trying to generate Windows bindings > from a Linux machine? While the code used to work differently (e.g. no > class cast exception), the bindings might behave unpredictably on > Windows. It probably just happened that you never worked with > libraries using `long` (which, for the portability issues you noted, > is often avoided). If you have e.g. a struct containing a long field, > the size and offsets of that struct would be completely bogus, so I > would not recommend to use jextract in that cross-platform way -- it > is not designed to work that way. The new error message points this > out a little earlier (before something worse occurs). > >> For instance the platform check could be done at runtime. > > Yes, but at the end of the day we have to assign either a `OfLong` > field, or a `OfLongLong` field. And we can't change the type of the > field at runtime. Which means the type of the field is picked at > extraction time (this was also the case before the fix), and at > runtime we cast whatever `canonicalLayout` returns to the expected > type (which throws if there is a mismatch). > > Perhaps, a slightly more lenient way to handle this would be to just > leave the layouts to `null` if there's a mismatch (instead of > throwing). This means that bindings only using "portable" layouts > would still work. But, while this might fix your issue, I'm not 100% > sure that would be much better in the general case. > > Maurizio > > From jextract at xpple.dev Mon Mar 31 11:58:07 2025 From: jextract at xpple.dev (jextract at xpple.dev) Date: Mon, 31 Mar 2025 13:58:07 +0200 Subject: Bindings crash on Windows where they would not before In-Reply-To: References: <460893d85393d128b451150c27f4a510@xpple.dev> Message-ID: <55aee231ad7045d34f2a6c35d79506bc@xpple.dev> Thank you for the responses! > Maybe the problem is that you are trying to generate Windows bindings > from a Linux machine? [...]. It probably just happened that you never > worked with libraries using `long` (which, for the portability issues > you noted, is often avoided). You could say that. Although, yes it is indeed the case the `long` type is not used in my case, so there should not be any real problems. > As a workaround, you could try deleting the layout for `C_LONG` in the > generated bindings. I thought of that too, but it is kind of manual (not ideal to automate). Since I am generating the bindings on GitHub Actions, it would be preferable if there were a more directly supported fix. Perhaps a CLI parameter to apply the lenience as described by Maurizio? > Perhaps, a slightly more lenient way to handle this would be to just > leave the layouts to `null` if there's a mismatch (instead of > throwing). Kind regards, Frederik van der Els On 2025-03-31 13:11, Jorn Vernee wrote: >> It probably just happened that you never worked with libraries using >> `long` > > I think this is probably the case as well. As a workaround, you could > try deleting the layout for `C_LONG` in the generated bindings. If the > library is indeed portal enough, there should be no compilation > errors. > > Jorn > > On 31-3-2025 11:02, Maurizio Cimadamore wrote: >> Hi, >> thanks for the report. >> >> I think the fix should still take into account for platform >> mismatches. Note that we now have a shared section, containing >> constants? for all platforms) and a follow up sections where we >> initialize platform-specific constants. >> >> The shared section only contains LONG_LONG, which is always 64 bits, >> even in Windows. >> >> The followup section contains LONG, which is 32bit/OfInt on Windows, >> and 64bit/OfLong elsewhere. What the follow up section does is >> determined by `TypeImpl.IS_WINDOWS`, which is defned here: >> >> https://github.com/openjdk/jextract/blob/master/src/main/java/org/openjdk/jextract/impl/TypeImpl.java#L45C1-L45C98 >> So, on Windows the right thing should happen. >> >> Maybe the problem is that you are trying to generate Windows bindings >> from a Linux machine? While the code used to work differently (e.g. no >> class cast exception), the bindings might behave unpredictably on >> Windows. It probably just happened that you never worked with >> libraries using `long` (which, for the portability issues you noted, >> is often avoided). If you have e.g. a struct containing a long field, >> the size and offsets of that struct would be completely bogus, so I >> would not recommend to use jextract in that cross-platform way -- it >> is not designed to work that way. The new error message points this >> out a little earlier (before something worse occurs). >> >>> For instance the platform check could be done at runtime. >> >> Yes, but at the end of the day we have to assign either a `OfLong` >> field, or a `OfLongLong` field. And we can't change the type of the >> field at runtime. Which means the type of the field is picked at >> extraction time (this was also the case before the fix), and at >> runtime we cast whatever `canonicalLayout` returns to the expected >> type (which throws if there is a mismatch). >> >> Perhaps, a slightly more lenient way to handle this would be to just >> leave the layouts to `null` if there's a mismatch (instead of >> throwing). This means that bindings only using "portable" layouts >> would still work. But, while this might fix your issue, I'm not 100% >> sure that would be much better in the general case. >> >> Maurizio >> >>