[External] : Re: GUI wrapper for jextract

Wed Oct 5 00:59:56 UTC 2022

>
> Isn't "include files path" suggestive enough?

I would say no. A path points to one file (or folder). If I have several
include files, do I specify this option multiple times? Do I point it at a
folder that contains the includes? If I can point it at a folder, does it
ignore other files in it? This isn't documented in --help or the README.

-D FOO=42 defines macro FOO with value 42 (as accepted by C compilers).
>

So the format is just a string, not a file containing the macro. If I have
multiple macros, do I specify the option once for each?

If you don't specify package, generated classes go into unnamed package and
> classes are generated in current dir . If you don't specify header class
> name, "file.h" is mapped as "file_h". Both of these can be seen by simple
> usage of jextract.

It can be tested for the current behavior, but it isn't the documented
behavior, or could be not the intended behavior. Granted, this is still in
development, but Java rarely works by "try an example and that's how it
works".

Thanks,
Nir

On Tue, Oct 4, 2022 at 9:56 AM Sundararajan Athijegannathan <
sundararajan.athijegannathan at oracle.com> wrote:

> jextract --help output contains these lines (also available as a table in
> the README.md file in the project page).
>
>
>
> -I <path>                      specify include files path
>
> Isn't "include files path" suggestive enough?
>
> -D <macro>                     define a C preprocessor macro
>
> "C preprocessor macro" as accepted by C compilers.
>
> -D FOO=42 defines macro FOO with value 42 (as accepted by C compilers).
>
> If you don't specify package, generated classes go into unnamed package
> and classes are generated in current dir . If you don't specify header
> class name, "file.h" is mapped as "file_h". Both of these can be seen by
> simple usage of jextract.
>
> -Sundar
> ------------------------------
> *From:* Nir Lisker <nlisker at gmail.com>
> *Sent:* 04 October 2022 02:49
> *To:* Sundararajan Athijegannathan <
> sundararajan.athijegannathan at oracle.com>
> *Cc:* jextract-dev at openjdk.org <jextract-dev at openjdk.org>
> *Subject:* [External] : Re: GUI wrapper for jextract
>
>
> 1 & 2 You may want to checkout https://github.com/openjdk/jextract
> <https://urldefense.com/v3/__https://github.com/openjdk/jextract__;!!ACWV5N9M2RV99hQ!Mazo0n821kiGiNzdX-0dCDVNST1uXWrfqlsw-6LEUs7MfISErCA4BBdv4zZHD3DQpi9hKmF7I-S0uagm09S8z8-BtmGw$>
>
> I already read everything there. I don't see the answers there.
> What happens if a package name or header class name are not specified?
> What does the path of -I need to point at? A folder? What file types are
> accepted?
> What format does a macro for -D come as? A file?
>
>
> 3. Options like -I and -l try to mimic same C compiler driver options
>
> Alright.
>
>
> 4. Need to check consistency with the rest of the JDK bin tools on this.
> Btw for embedding use case, you can use ToolProvider API which jextract
> supports. No need to fork a separate process and deal with streams etc.
>
> I wasn't familiar with this API; I will study it. Thanks.
>
>
> 5. Not getting your use case. "dump" is to get all symbols from header
> parsed - which you can edit and use it as argument in a later jextract
> session. That's use the intended use case.
>
> The GUI wrapper reads all the symbols and allows the user to choose which
> ones they want to bind to. This replaces the need for the user to modify a
> text file. Think of a tree view:
>
> [ ] myheader.h
>   [ ] funcions
>     [X] myfunc1
>     [ ]  myfunc2
>   [X] structs
>     [X] mystruct1
>     [X] mystruct2
>
> This representation is easier to work with (batch selection etc,), but to
> build it, a dump output is required. When the tool gets a header, it runs
> --dump-includes on it, but doesn't want a file to be created, read, and
> deleted. It wants the output directly "in memory".
>
> 6. jextract supports only C language - the file extensions that "clang"
> compiler accepts for C programs should work.
>
> Alright, thanks.
>
> - Nir
>
> On Mon, Oct 3, 2022 at 6:34 AM Sundararajan Athijegannathan <
> sundararajan.athijegannathan at oracle.com> wrote:
>
>
>    1. & 2 You may want to checkout https://github.com/openjdk/jextract
>    <https://urldefense.com/v3/__https://github.com/openjdk/jextract__;!!ACWV5N9M2RV99hQ!Mazo0n821kiGiNzdX-0dCDVNST1uXWrfqlsw-6LEUs7MfISErCA4BBdv4zZHD3DQpi9hKmF7I-S0uagm09S8z8-BtmGw$>
>    2.
>
>    <https://urldefense.com/v3/__https://github.com/openjdk/jextract__;!!ACWV5N9M2RV99hQ!Mazo0n821kiGiNzdX-0dCDVNST1uXWrfqlsw-6LEUs7MfISErCA4BBdv4zZHD3DQpi9hKmF7I-S0uagm09S8z8-BtmGw$>
>    GitHub - openjdk/jextract: https://openjdk.org/projects/code-tools
>    <https://urldefense.com/v3/__https://github.com/openjdk/jextract__;!!ACWV5N9M2RV99hQ!Mazo0n821kiGiNzdX-0dCDVNST1uXWrfqlsw-6LEUs7MfISErCA4BBdv4zZHD3DQpi9hKmF7I-S0uagm09S8z8-BtmGw$>
>    Jextract. jextract is a tool which mechanically generates Java
>    bindings from a native library headers. This tools leverages the clang C
>    API in order to parse the headers associated with a given native library,
>    and the generated Java bindings build upon the Foreign Function & Memory
>    API.The jextract tool was originally developed in the context of Project
>    Panama (and then made available in the ...
>    github.com
>    <https://urldefense.com/v3/__http://github.com__;!!ACWV5N9M2RV99hQ!Mazo0n821kiGiNzdX-0dCDVNST1uXWrfqlsw-6LEUs7MfISErCA4BBdv4zZHD3DQpi9hKmF7I-S0uagm09S8z9jv0OfV$>
>
>
> 3. Options like -I and -l try to mimic same C compiler driver options
>     4. Need to check consistency with the rest of the JDK bin tools on
> this. Btw for embedding use case, you can use ToolProvider API which
> jextract supports. No need to fork a separate process and deal with streams
> etc.
>     5. Not getting your use case. "dump" is to get all symbols from header
> parsed - which you can edit and use it as argument in a later jextract
> session. That's use the intended use case.
>    6. jextract supports only C language - the file extensions that "clang"
> compiler accepts for C programs should work.
>
> -Sundar
>
> ------------------------------
> *From:* jextract-dev <jextract-dev-retn at openjdk.org> on behalf of Nir
> Lisker <nlisker at gmail.com>
> *Sent:* 03 October 2022 03:01
> *To:* jextract-dev at openjdk.org <jextract-dev at openjdk.org>
> *Subject:* GUI wrapper for jextract
>
> Hi,
>
> After a short talk with Maurizio off-list, I started making a GUI wrapper
> for jextract. I have several question/comments that came up during
> development:
>
> 1. In order to help the user give the correct inputs, is there more info
> somewhere on what each command accepts exactly? For example, what does '-I
> <path>' look for exactly in the path? What does '-D <macro>' look for?
> 2. What are the default values for options that aren't specified and have
> to have a default, like the output path, package name, and header class
> name?
> 3. I think that having a capital I and a lowercase l options is confusing
> in many fonts. Is there a reason not to use lowercase or uppercase on
> everything?
> 4. I execute jextract using a java.lang.Process object and read its output
> and error streams. I noticed that the process writes the output of
> '--version' and '--help' to the error stream, while it makes more sense to
> write them to the output stream. I'm on Windows in case it's OS dependent.
> 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.
> 6. What file formats, except for .h, can jextract expect as a target? .c?
> .hh?
>
> Thanks,
> Nir
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20221005/32e043e4/attachment-0001.htm>