GUI wrapper for jextract

Sat Oct 8 22:50:15 UTC 2022

Hi Maurizio,

Yes, this is much clearer! I didn't see the PR or I would have noted a few
points there. I'll do it here now:

1. For macro, the Option column is great, but the Meaning column is
cryptic: "define to (or 1 if omitted)", to what? 1 what?
2. For --library, I would write in the Meaning column what file types are
accepted. I believe they are only .dll, .so, and .dylib. If this is obvious
then you can ignore this point.
3. Since --include-dir in its Option column specifically specifies <dir>
(which is great!), I would think about being specific like that in the
other options too. --library uses <path> that actually means <file>
(although you show this in the example under Meaning); --output uses <path>
that means <dir>, although this one is rather obvious because there's no
other option; --dump-includes specifies <String>, but is it just a name or
a can it be a whole path? (The example below shows how to use it with a
name.)

On the interfacing side, I'm still stuck with the issue of dependencies.
While I can compile with jextract's javac and pointing to the jmods of the
JDK, I can't do it during runtime (execution of 'java'). I'm still using a
Process with streams in the meantime.

Thanks,
Nir

On Sun, Oct 9, 2022 at 12:02 AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> 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 19  Main.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/20221009/c5d85eb4/attachment-0001.htm>