GUI wrapper for jextract

[Maurizio Cimadamore]

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/20221004/a8f0cf3f/attachment.htm>