GUI wrapper for jextract

[Nir Lisker]

With some help, I managed to load Jextract as a dependency and interface
with it directly. When looking at the API, I found a small inconsistency:
The --include- options are function, macro, struct, union, typedef, and var.
The Declarations that match these seem to be Function, Constant,
Scoped.Kind.STRUCT, Scoped.Kind.UNION, Typedef and Variable.
Maybe the macro option and Constant Declaration should use the same
terminology. I would have thought that defining 'const' in the header file
will map to Constant, but it maps to Variable, and defining a macro with
`#define` is what maps to Constant.

- Nir

On Sun, Oct 9, 2022 at 11:55 AM Nir Lisker <nlisker at gmail.com> wrote:

> Another point that I missed is: when specifying a directory path for
> -include-dir, the docs don't say if the search is recursive (searches also
> within folders with the directory).
>
> On Sun, Oct 9, 2022 at 1:50 AM Nir Lisker <nlisker at gmail.com> wrote:
>
>> 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/20221014/a6113564/attachment-0001.htm>