GUI wrapper for jextract

[Maurizio Cimadamore]

Hi Nir,
we have made some tweaks to the command line option description:

https://github.com/openjdk/jextract/tree/panama

Hopefully that should reflect some of the discussion in this thread.

Thanks
Maurizio


On 06/10/2022 20:43, Nir Lisker wrote:
> I tried the workaround. Compilation is fine, but during runtime I get:
>
> Error occurred during initialization of boot layer
> java.lang.module.FindException: Module java.desktop not found
>
> What is the run command that adds all the jdk modules?
>
> On Thu, Oct 6, 2022 at 8:35 AM Sundararajan Athijegannathan 
> <sundararajan.athijegannathan at oracle.com> wrote:
>
>     Binary download of jextract does not include
>     org.openjdk.jextract.jmod file (although that is part of jextract
>     build folder).
>
>     For now, you can workaround using the following:
>
>
>     $ cat Main.java
>
>     import org.openjdk.jextract.*;
>
>     import java.awt.*;
>
>
>     class Main {
>
>     public static void main(String[] a) {
>
>     System.out.println(Frame.class);
>
>     System.out.println(JextractTool.class);
>
>     }
>
>     }
>
>
>     # assume that the current directory is "bin" dir of
>
>     # jextract tool. It has a javac executable in it.
>
>     # We use jextract's javac but pass module-path for the
>
>     # other jdk modules not included in jextract jdk image.
>
>
>     $ ./javac --module-path
>     /Library/Java/JavaVirtualMachines/jdk-19.jdk/Contents/Home/jmods
>     --add-modules java.desktop --enable-preview --source 19Main.java
>
>
>
>     If you're okay with building jextract from the sources, then you
>     use JDK 19's javac with the following option:
>
>     --module-path $JEXTRACT_REPO/build/jmods
>
>
>     [That directory $JEXTRACT_REPO/build/jmods contains
>     org.openjdk.jextract.jmod module file]
>
>
>     -Sundar
>     ------------------------------------------------------------------------
>     *From:* jextract-dev <jextract-dev-retn at openjdk.org> on behalf of
>     Nir Lisker <nlisker at gmail.com>
>     *Sent:* 06 October 2022 07:51
>     *To:* Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
>     *Cc:* jextract-dev at openjdk.org <jextract-dev at openjdk.org>
>     *Subject:* Re: GUI wrapper for jextract
>     Yes, if I can interface with the tool directly it would be ideal.
>
>     How can I add jextract as an external dependency for this? The
>     jextract build is not a full jdk, and I'm running on jdk-19.
>
>     On Tue, Oct 4, 2022 at 12:19 PM Maurizio Cimadamore
>     <maurizio.cimadamore at oracle.com> wrote:
>
>         Hi Nir,
>
>         On 02/10/2022 22:31, Nir Lisker wrote:
>>         5. When analyzing the symbols of a header using the dump
>>         option, I need to read the file that jextract creates from
>>         disk and then delete it. Is there a way to read the jextract
>>         output directly? Either through the output stream, or writing
>>         to a file in memory? Dealing with disk I/O is cumbersome,
>>         comes with permission restrictions, and might be slow if done
>>         for many files in a batch.
>
>         I think ultimately, working with files might be not ideal for
>         your use case.
>
>         There is a pseudo-stable API to parse jextract files, in the
>         JextractTool class (in the org.openjdk.jextract package, which
>         should be exported by the jextract module):
>
>         `public static Declaration.Scoped parse(List<Path> headers,
>         String... parserOptions) {`
>
>         We do not make any promise (at this stage at least) on the
>         stability of the API. That said, it has not changed much (at
>         all?) in the last couple of years.
>
>         What you get back is a "Declaration", which is used to model
>         vars, structs, unions, typedefs, functions
>
>         Then, attached to declarations, there are "Type"s, which are
>         used... well, to model types. Since some type can be
>         structured (e.g. a struct type), they can point back to their
>         declaration (e.g. Type.Declared).
>
>         Jextract does all it does by defining visitors on this basic
>         declaration tree, which is obtained by wrapping the results of
>         parsing a C header using the clang API (e.g. clang Cursors).
>
>         We did this to "sanitize" the output of clang, as well as to
>         make our implementation more robust and less dependent from
>         clang internals.
>
>         One option for you would be to invoke the parsing process this
>         way, then get the tree and look at the results (e.g. with a
>         visitor), which sounds better than parsing an option file.
>
>
>         Cheers
>         Maurizio
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20221008/b2e10af9/attachment-0001.htm>