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