<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Note that --dump-includes already exists, and generates a flat list of `--include-XXX` options that can be passed back to jextract (not JSON).</blockquote><div><br></div><div>I saw that, but these are just string names. They don't contain all the info in a Declaration, which can be useful to the user.</div><div><br></div><div>And it still adds extra steps. When jextract receives a head, it generates a list of Declarations. Now, instead of directly sending it back, it maps them to strings (in whatever format) and writes them to a file; then an application needs to read that file and parse the strings back to Declarations. But we already had these Declarations to begin with.</div><div>The way I see it, jextract has 2 functions: inspect a header(s), and generate bindings for a header(s). While ToolProvier#run covers these, it requires extra hoops to jump through, such as the above parsing and also reading messages from the standard streams. Removing the exception on a parsing error was enough to disable one of the features of the app that informs the user that an include dir is missing.</div><div><br></div><div>If you're interested, I can give you and anyone else in the jextract team access to the repo and you can try it out, although it's still in beta. I intend to make it public anyway when I can prove it works on non-Windows machines.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Jan 30, 2025 at 8:20 PM Jorn Vernee <<a href="mailto:jorn.vernee@oracle.com">jorn.vernee@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>Note that --dump-includes already exists, and generates a flat
list of `--include-XXX` options that can be passed back to
jextract (not JSON). You would need to parse these options
manually. I think the format would be relatively stable, only
needing to change if we change the command line options.<br>
</p>
<p>> Speaking of 'parse', I notice that it doesn't throw an
exception on a missing '#include <header.h>' as it used to.
Now I only see a printed error. Has this changed? Is there a way
to capture this error somehow so that the user knows something
went wrong?</p>
<p>Yes, this changed as part of:
<a href="https://github.com/openjdk/jextract/pull/255" target="_blank">https://github.com/openjdk/jextract/pull/255</a><br>
<br>
It looks like the Logger class that was added is not part of the
public API, so right now I don't think there's a way to capture
those errors aside from capturing and parsing them from the
output.</p>
<p>Jorn<br>
</p>
<div>On 30-1-2025 14:06, Nir Lisker wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">It's probably possible to do, but looks roundabout.
<div><br>
</div>
<div>Here is my setup in more detail:</div>
<div>1. A header is given to the application. It calls 'parse'
on it to get all the Declarations.</div>
<div>2. The user can configure which declarations to include in
the GUI, and also the other options such as class name,
macros, output dir etc.</div>
<div>3. The 'run' method is called with the arguments generated
from the configuration.</div>
<div><br>
</div>
<div>It's all in-memory.</div>
<div><br>
</div>
<div>With --dump-includes:</div>
<div>1. A header is given to the application. A JSON file is
created.</div>
<div>2. The file is read and parsed to produce the Declarations.
Configuring a JSON parser is already a lot of work
for polymorphic sybtyping (all the types of Declarations).
Will jextract provide a parser? What is the format? Is it
stable?</div>
<div>3. Is 2 above.</div>
<div>4. Is 3 above.</div>
<div><br>
</div>
<div>So we complicated things by creating a file from which we
need to read the data that would otherwise be given to us
directly by 'parse'. At least this is my understanding.</div>
<div><br>
</div>
<div>Speaking of 'parse', I notice that it doesn't throw an
exception on a missing '#include <header.h>' as it used
to. Now I only see a printed error. Has this changed? Is there
a way to capture this error somehow so that the user knows
something went wrong?</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Jan 28, 2025 at
5:06 PM Jorn Vernee <<a href="mailto:jorn.vernee@oracle.com" target="_blank">jorn.vernee@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>> There is no need for a dump.<br>
<br>
But, do you think you could do the things you're doing,
using JextractTool::parse, by using --dump-includes
instead?</p>
<p>I'm trying to assess if we even need the API at all, or
if we can just have the ToolProvider.<br>
</p>
<p>Jorn<br>
</p>
<div>On 28-1-2025 15:12, Nir Lisker wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">I use
<div>JextractTool.parse(List<String> arg0,
String... arg1)</div>
<div>to inspect given header files. Then I use</div>
ToolProvider.run(PrintStream out, PrintStream err,
String... args)
<div>which is not Jextract-specific to run the tool with
the user's configuration. There is no need for a dump.</div>
<div><br>
</div>
<div>I want to release an alpha soon so you'll be
able to see how it works.</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Jan 28, 2025
at 2:28 PM Jorn Vernee <<a href="mailto:jorn.vernee@oracle.com" target="_blank">jorn.vernee@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey
Nir,<br>
<br>
The jextract API has been neglected for a while (as
you've found). <br>
Initially it was a way of avoiding adding many flags
to jextract, to do <br>
things like filtering, renaming, and other things. The
idea being that <br>
if users wanted more control of what jextract did,
they could use the <br>
API. But, now it seems like we're moving in that
direction any way, with <br>
the JSON based configuration: <br>
<a href="https://bugs.openjdk.org/browse/CODETOOLS-7903788" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/CODETOOLS-7903788</a><br>
<br>
I think we need to re-asses which use cases the
jextract API addresses, <br>
and whether using jextract through the ToolProvider
interface, with the <br>
extended configuration options, is also an option.<br>
<br>
IIRC your use case is filtering the jextract output,
right? Do you think <br>
it would be possible to use the ToolProvider interface
with a <br>
combination of --dump-includes, and automatically
generated <br>
--include-XXX flags, to achieve the same level of
functionality?<br>
<br>
Jorn<br>
<br>
On 26-1-2025 08:51, Nir Lisker wrote:<br>
> Hi,<br>
><br>
> There are several public methods the
JextractTool exposes. Please <br>
> javadoc to these methods so tool users will know
what they do and how <br>
> to use them.<br>
><br>
> Thanks,<br>
> - Nir<br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote></div>